Famo.us – Scrollview

Famo.us

I really like the look of Famo.us, I just haven’t had the time to play with it much. I had some time today, and thought I should wait no longer! Having already done the tutorials on the Famo.us University pages, I thought I’d try and tackle some more practical problems.

Scrollview

When making mobile applications, the scrollview is ubiquitous. This is a UI widget that shows up everywhere and has so many uses. Luckily Famo.us has a an example in their Starter Kit. Download it from their home page.

The scrollview example is located in reference-examples/views/scrollview.

Take a look at the example itself. The code looks pretty simple, if you’ve gone through the University Tutorials, you should recognize many of the features. Open the example in a browser and test it. Just a set of colored rows with a single line of text. The scrollview doesn’t scroll with a click and drag. It does scroll with a swipe on the track pad. This doesn’t look like it’s doing anything, or is it? Try it in the iOS simulator, or on your mobile device. Here it scrolls with a swipe as expected.

Screen Shot 2014-09-19 at 12.10.43 PM

Take a look at the files in the example folder. There are really two files:

  • index.html
  • src/main.js

Looking at index.html you will see that there is not a whole lot there. There are a few links to js files, that are commented as “Shims for backwards compatibility.” I’ll guess these are not necessary for modern browsers. Then there is a section commented as “famous.” I’ll take a guess that this is the main famous stuff. This section has two style sheets and two js scripts. The first script loads famous from the famous CDN. While the second script loads “src/main.js”, which is the example js.

Take a look at main.js. Overall this is pretty short. The code is wrapped in a define() block. The function passed to define must be called when the rest of the famous and the DOM is loaded. Here require() is used to load modules of the famous code base.

  • Engine
  • Surface
  • Scrollview

After the requires, a context is created, mainContext. The context is the container that renders surfaces.

Next is a new Scrollview object is created.

Then a an empty array, surfaces, is defined. The array is passed to the scrollview object via sequenceFrom().

A note on scrollviews. In general these are set up to display items from a list, or array. The scrollview only displays the rows that are currently visible. If you have a list containing thousands of items, I imagine your iTunes library has thousands of items, your mobile computer does not have enough memory to display all of these as one giant list. Instead the the computer displays only the rows that are currently visible on the screen. I’m guessing Famous is using the same strategy. Hence it needs a list of surfaces to display. The scrollview will mange displaying these surfaces.

Next there is a for loop that builds surfaces and adds them to the surfaces array. Each surface is created with newSurface(). The content of a surface will be the text: “Surface: #”, where # is the number of the surface. The width is undefined, I’ll guess this allows the surface to be any width, and the height is 200 px. Next the surface is assigned properties. The background color, line height, and text align. These are standard CSS properties.

Each new surface was created in a local variable named temp. Next we’re calling the pipe() method and passing a reference to the scrollview. I’m not sure what this doing, I’ll have to revisit the Famous University.

Next push each new surface into the surfaces array.

Last, add the scrollview to the mainContext with add().

What next?

The best way to understand how these things work, and to develop ideas as to how you can use them for your own projects is to experiment! The best way to test these things is to start small. Making small changes and testing to observe the results.

As a start lets work with the content. Line 52 shows:

This seems to be the content of each row in the scrollview. Let’s play with this and test that assumption. Change the content, try making these changes:

  • Change the text
  • Add HTML tags to format the text

Next change the size of the rows. As is each row 200 px tall, note that the content has a line height 200 px which places the text in the vertical center, and also makes the text take up the whole height of the row.

Change the line height to something more smaller. Add a second line of content to each row.

Try out these properties:

  • fontFamily, fontSize, color
  • border, borderTop

Customize row content

The tableview is not very useful if you can’t customize the content of each row. In the example, rows are generated within a loop, and the only real content is the row number.

Make an array to mock up some more relevant content. The demo uses a loop:

Try replacing this with an array. Define an array and then loop through the array:

With this you should see the same rows, but only as many rows as you have elements in the array. Now display the content from the array. Find where the content property is set for the surface. Try this:

At this point you should see something like: “Surface: A 0″ for each row. You can use HTML and CSS in here also. Imagine this:

Add a class name. You’ll need to style this class in your style sheet.

Watch the quotes carefully. Attribute values must always be in quotes. Since the outer quote is a double “, the inner quotes need to be single ‘.

Adjust the height of the cell.

The example adds a few properties like:

These these generate CSS properties that are attached to the row element as inline styles. Prove this to yourself. Use the inspector to view one of the scrollview cell rows. You should see something like:

This shows each row is displayed from a div with a famous class, and some style properties. Some of the properties are applied by famous, while others were added by us when the surface was created.

I think it’s probably better to move our styles to a style sheet. At this point it’s hard to say if this is best practice for Famous. In any regular HTML page it would definitely be best practice.

Note that the color value is generated for each row, the value is based on the row number. It’s this system that gives us the great rainbow effect. For styles that need to be generated on the fly based on data only available when the surface element is created, setting the properties here is a good idea. For general properties, I’m guessing it will better to use a style sheet.

 

 

 

 

 

 

HTML5 is there yet?

Here are some thoughts on HTML5 and whether it’s up to the task of making mobile apps.

Mobile browsers lag, so mobile HTML5 apps suffer

This article from principal HTML5 evangelist at Mozzilla. He says browsers are not up to the task. This is coming from someone at a company that makes browsers. He’s saying the browsers don’t do enough to satisfy the vision that everyone has for HTML5. I have to ask is that a problem of the browser really? Is this a case where someone is saying “hey your browser needs to live up to my vision.”

He also says:

HTML5 is a recognized as a set of standards-based specifications for so-called modern Web applications with multimedia capabilities, leveraging JavaScript and Cascading Style Sheets.

After reading this I had to ask. Is a web browser with multimedia capabilities really the platform to deliver full feature mobile applications?

Here’s another article

Forrester: HTML5 apps still not as good as native apps

Here is a quote:

But adopting HTML5 for mobile apps isn’t a panacea, as reflected in Forrester’s findings. In fact, one of the report’s survey responses noted that 59 percent of the time, apps developed solely using HTML5 took longer to deliver than planned. With non-native responsive frameworks, the greatest amount of time was lost testing and fixing issues.

The survey of developers says 59% of the time HTML5 apps took longer to develop.That flies in the face what people have been touting as common wisdom for the last few years. It seems to fit with my limited personal experience.

Here’s another survey:

Mobile app development: 94% of software developers bet on HTML5 winning

This survey from 2012 says an overwhelming percentage of developers are planning to use HTML5 to build their apps. Their top reason: familiarity with the languages HTML/CSS/JS. I have to ask is that the right reasoning? Admittedly the second most popular reason was cross platform compatibility. You can only imagine that wanting building apps in HTML5 since it is more familiar means that these people do not want to spend time learning a native development tool, and they thought it would be faster and easier. In the article above, from 2014, two years later, shows that a majority of developers agree that it took longer to develop their apps in HTML5. I can imagine that a fair amount of apps took just as long it would have taken to develop native. A few may have been developed faster. But for the majority it was longer or about the same, to develop an app that will lower performance than a native app.

Not sure this looks like it may have come from the same survey above, but doesn’t appear in that article:

Survey: Most Developers Now Prefer HTML5 For Cross-Platform Development

Again here they show 90% of developers using HTML5. I work with students developing apps, and many students want to use HTML5. Many for the reasons popular in the article above, ease and familiarity. I would say a majority of the projects are social media. Notice the chart here labeled types of apps. The most popular app is productivity at 54%, social media apps is 18%.

You could say that social there are fewer people developing social media, and that may be true, it’s hard to say from this chart. Look at games only 8%. Games have to be in the top three for shear volume in apps. Social media apps are also very popular. Looking at the chart in this light, you might start to think that people are choosing native for games and social media. Obviously you can’t make a definitive conclusion like this from this information, but it does hint that there is more to this than the 90% figure.

Also note that the survey was conducted by Telerik kendo UI who develop an HTML5 mobile framework. Some of the questions skew in the favor HTML5 like:

  • Only 15% of the more than 5,000 surveyed would use “Native-only” to target multiple platforms

Targeting multiple platforms with native is native’s biggest disadvantage.

I went out on a limb earlier and said that native apps had better performance. What does that mean?

Americans Prefer Native Mobile Apps Over HTML: Survey

This survey says people prefer native apps. Here’s a quote:

“Smartphone home screens across the country are littered with the tombstones of mediocre, try-once-and-forget apps,” Joseph Farrell, executive vice president of operations at Bite Interactive, said in a statement. “Brands and developers too often lose sight of the most important aspects of developing mobile applications: build in-brand, powerful and highly usable apps that continually deliver real value to your users by solving the problem they have asked you to solve. Delivering continued, iterative and brilliantly executed solutions to those evolving problems should always be the primary objective.”

I think this is a good point. Developing an app faster (or may be not faster) for less, is this a good thing when the user experience is poor? Did you really save time and money? Was your time and money well spent? Maybe not.

From a user perspective native is better. From a developer perspective HTML5 seems to be preferred. Think about that for a moment. Is this the cart driving the horse? shouldn’t a developer want to produce the app that will provide the best experience and performance for a user? Seems like there is little advantage in choosing to develop an app in HTML5 because you are familiar with it, rather than it is the best tool for the job.

But wait, there’s more. Here’s another.

Mobile app developers’ interest in HTML5 is slipping

Here’s an interesting paragraph:

This was the lowest level since Appcelerator began tracking the specification in April 2011. “Interest in HTML5 peaked in July 2012 at 72.7 percent and has shown and uneven but downward slope since,” the report said.

I think this is referring to the same survey that showed HTML5 down to 59%. They mention a downward trend. There isn’t a chart or reference to this, which is too bad. It should be noted, that the survey mentioned here is from Appcelerator, which is a JS based pseudo native app development tool.

Here’s a quote from another source:

In the battle between HTML5 and native apps, HTML5 is starting to become a strong contender. While native app approaches have been a top choice in the past, a recent survey revealed that 57% of participants believe HTML5 is enterprise-ready, or will be in within the next year.

I have been hearing this for a few years now. Note the article was from 2013. We’re in the fourth quarter of 2014, and I think it’s still debatable if HTML5 is “enterprise ready.”

Seems the real advantage to HTML5 for mobile apps is, that it is faster and easier to develop. Keep in mind that the earlier survey said 59% of developers thought it took longer to develop in HTML. Users also prefer native. In this light the advantages of HTML5 seem very slim to nonexistent.

Why post this? I don’t have an axe to grind, but I do feel there is a lot of hype in HTML5 these days. And it’s easy to see it as a good fit for everything. I feel this approach is not the correct approach. Without applying an honest critique to what is happening in the real world you run the risk of choosing a tool that is not the best fit the job. Which leaves you with a poorly performing product and more hassle than necessary. I believe there is a class of app that works well with HTML5, but it’s a small subset of all of the apps you could make. I also believe that the margin in development effort between native HTML5 much slimmer than what most people would suggest, and possibly nonexistent. If there is an advantage to HTML5, it’s in distribution.

 

 

Logo as ing or h1

I get this question a lot, here are a few thoughts.

Think about it this way, the alt attribute might tell you what it is if it’s worded well. Bu, even if it is worded well, is it what the page is about? We don’t know. We can’t be sure because the alt is just a description of the the image. The h1 on the other hand is very clearly a very important heading. This is very clear.

Consider a page with these two images:

img alt=”cat”

img alt=”Pepsi”

Is the page about cats or is it about pepsi? You can’t tell. The page might be about Pepsi with a picture of a cat enjoying the pepsi, imagine it’s part of Pepsi’s new ad campaign that takes advantage of the internet’s love of cats.

Or, in an alternate universe, imagine that the page is a cat fancier blog, with a picture their cat named Pepsi. It could happen, Pepsi is a cute name, they already have another cat named Moxi.

Now consider this markup.

h1 Pepsi /h1

img alt cat

The h1 tag clearly says this page is about Pepsi, whether it’s the cat or the drink might have to be determined by meta data. There is no mistaking that Pepsi is more important than cat. Pepsi is a very important heading, while cat is merely an alternate text description of the image.

Using this markup, we’re also clearly describing the content and presentation. Pepsi is the name of the site so we use text. Cat is a picture on the page, presumably a picture of a cat, the computer can’t be sure the picture is actually a Cat, or the logo of a multinational corporation. Consider that in the context of the first example for a moment. Catapillar tractor abbreviates their name as Cat. It’s printed on everything this. I seeing even more room for confusion in the first example.

Using this arrangement we also get the advantage of displaying the logo as text, or as any range of alternate images, based on media queries. The look of the h1 is fully handled by our stylesheet. Mulitnational corporations like to have their logos appear in very specific ways depending on context.

Overly clever readers are thinking, what about this:

img alt=”Cat, the Catapillar company logo”

img alt=”Pepsi our peppy new skid steer loader”

While this is more descriptive it requires a fairly intelligent system to examine the alt text and come up with a meaning. While the Google algorithms are pretty smart, I still feel there’s room for error. And all of the non Google algorithms fail.

Objective-C – Delegates and Protocols

The delegate design pattern creates a system wherein one object passes work to another object. The first object stores a reference to another object, it’s delegate, and calls methods in the delegate object.

To make this system work there are two problems to solve. First. the main class needs a reference to the delegate object. The second problem is the need for the delegate object to implement the methods the delegator object will invoke. Without this guarantee your program runs the risk of no working or crashing.

The first problem is easily solved by adding a property to the delegator that holds a reference to it’s delegate object.

The second problem is solved by declaring a protocol. A protocol declares methods and properties that an object will invoke in it’s delegate. Any class that will act as a delegate implements the protocol, and the methods the defined in the protocol.

When the compiler sees a class that implements a protocol, it checks that the methods declared in the protocol are defined in that class. If not you get a warning or an error.

Declare a protocol in the header file above of @interface with:

Declare a delegate property to hold an object that implements the protocol. The delegate property should be weak to avoid dependancies!

Use the id type here since the delegate object could be of any type.