Archive for the ‘Mobile’ Category

What all mobile web devs should know about PhoneGap

If you already building or looking into getting started with mobile web applications you should understand the basics of PhoneGap. The name ‘PhoneGap’ is widely recognized, and perhaps more widely misunderstood.

The nudge to write this article was born out of conversations where we stumbled across concrete limitations to modern responsive JavaScript libraries such as bootstrap and jQuery. Limitations that cannot be overcome by adding more brilliant functionality because some JavaScript capabilities simply do not exist within the browser today. Furthermore, other requirements were imposed by political realities, timeframes and expectations.

That’s where PhoneGap steps in. 

So what, tell me what PhoneGap does?

PhoneGap is owned by Adobe and it has an open source top-level Apache Foundation sister project called Cordova. I won’t bore you with its long and twisted history, you can read about it here if you want.

The bottom line is PhoneGap allows you to develop JavaScript mobile applications that have access to certain aspects of the native device such as writing data to a filesystem. Your web application is wrapped within a native mobile application container that gives you JavaScript access to native operating system capabilities beyond what the browser itself is capable of doing!

By native I mean iOS Objective C, Android Java, WindowsPhone, Windows 8, Blackberry 10, Amazon Fire OS and Tizen. Your JavaScript applications runs in a chrome-less browser that gives you special hooks to the operating system. You can also submit PhoneGap applications to the AppStore, Google Play and others.

Who uses this stuff, well you may be using a PhoneGap app from one of these online stores and not even know it. To mention a few: Southwest Airlines and many others.

What limitations can PhoneGap address that responsive libraries don’t?

If your requirements call for all or most of the following items, then PhoneGap is the correct choice for your project today. That may change as HTML5 continues to rapidly grow, but for now I’m sticking with the following bullet points. Stick with me and read through all of these before starting to throw out counter arguments.

JavaScript skillz. If you are an existing JavaScript shop, then PhoneGap leverages your existing JavaScript skills to access capabilities beyond current browser functionality without the need to have an in-depth understanding of Objective C or Java.

Sure, it’s easy to say you can hire expert contractors to develop iOS and Android applications, along with UX designers and testers. But, if your budget doesn’t include the capital costs for these folks and all you have is JavaScript ninjas on staff then the choice is easy.

Or, maybe you have genius-level developers that could easily and quickly spin up on all your need to know on ObjectiveC and Java Android. If this isn’t the case, and your timeframes and budgets don’t allow for this then you’ll need a fallback plan such as PhoneGap.

Access to camera.  Yes, you can currently access the camera on some web browsers today. However, the support on mobile browsers is still inconsistent, limited or non-existent. On the other hand, native device OS’s are expected to have access to cameras If they didn’t it would be considered a serious oversight. PhoneGap provides cross-platform mobile device access to the camera.

Read/write access to SD Card. Just to reiterate, this is both read and write access to a local storage device. Certainly there is a FileReader API in plain old JavaScript, but as far as I know there isn’t a FileWriter or its equivalent yet. If you need the write access to go along with read capabilities then you should be looking at PhoneGap.

[Correction Jan. 27, 2014] I mis-wrote. The FileWriter API exists however it has limited supported across browsers: http://caniuse.com/#search=filewriter. And, examples of it’s use can be found here.

AppStore or Google Play. If you have a requirement to submit your application to the app store then PhoneGap will help you get there. There is no way today for submitting a stand-alone web application for acceptance on AppStore or Google Play. Period. Some will argue that the need for using these online application stores is going away, but that’s a non-issue if you have been directed to meet this requirement a.s.a.p. and your job depends on it. If that’s the case, then PhoneGap will be your friend.

Is there anything else I should know?

Yes…First, PhoneGap is not perfect, but then again few software projects are perfect. You will need to install and know a few things about the native IDEs you want to support. If you want to deploy Android you’ll need to install Eclipse or IntelliJ. For iOS you’ll need to install XCode. Etc. You still have to compile a native project or you can try your hand at Adobe’s PhoneGap Build, which is a cloud based build system for PhoneGap.

It is confusing that there are two projects that share a common/similar code base: PhoneGap and Cordova. Also, Cordova’s documentation has typically been more up to date that Adobe’s. If you do your research you’ll find various performance complaints and bug issues (like I just said are there any software projects that don’t have these??).  Yet, overall it’s a great starting point if you have the needs listed above, and it’s much better than trying to start from scratch given today’s dramatically shortened delivery expectations.

You can absolutely still use bootstrap, jQuery and other JavaScript libraries within PhoneGap. There are caveats, of course, related to application life-cycle issue, navigation as well as App Store and Google Play user interface acceptance guidelines.

If you want to add functionality to PhoneGap because you find some critical thing is missing that you need for your project, the good news is you can develop a custom plug-in.

Last, I should mention Titanium Studio. It also lets you leverage JavaScript skills, with the primary difference being that it converts JavaScript into native byte code rather than just displaying it in a chrome-less view.  Plus it’s comes with its own IDE and MVC Framework.  I’ve never used Titanium so I can’t judge it, however I know people who do use it successfully and love it. It’s one more thing to consider that you should be aware of.

References

Cordova Documentation

PhoneGap Documentation

PhoneGap Platform Support

Tags: , , , , , , ,
Posted in JavaScript, Mobile, PhoneGap | No Comments »

Going Mobile with Blogging – Part 4

It has been one year since I upgraded my blog to be mobile friendly. This was mostly as an experiment. I haven’t received any complaints so I’m guessing that’s a good thing. I’m getting about 700 unique mobile visitors monthly averaging just over 4000 page views and that’s a decent average of just under 6 pages viewed per visit. and it’s slowly trending upwards. I knew from my website analytics that mobile visitors are  just a small percentage of my blog’s overall traffic. Before I researched the mobile stats, I had expected it to be a larger percentage given how much time people spend on their smartphones. But I’m guessing most people spend the vast majority of their time either playing games or messing around on facebook and other social media rather than reading technical blogs. That makes sense.

The vast majority of the mobile traffic is from smartphones, with tablets and iPads representing a very small minority of visits. That really surprised me as I figured anyone who is blog surfing would be using a larger device.

Here’s a rough breakdown of operating systems and versions for the last month:

Apple 41%

  • 71% iOS 6
  • 29% iOS 7

Android 59%

  • 99% Android 4.x
  • 33% Android 4.4!
Tags: ,
Posted in Mobile | No Comments »

6 myths on migrating from web to mobile

If you have a public facing website today, then it should be mobile enabled. Period. In this post when I say mobile I’m referring to both native and web mobile. There are an endless variety of articles discussing the benefits of moving from web to mobile, however there are very few articles on the internet that discuss the costs of migrating from a traditional web software development environment to mobile. And, yes, in 2013 there are still some major and not-so major companies that haven’t migrated to mobile. I think the best way to start talking about costs is to expose some common myths.

These myths are more about discussing the impact of not “going mobile” and adjusting to an increasingly mobile-friendly world. Consider your users to be the experts on what the mobile experience should or shouldn’t be like. Remember, building mobile web sites and apps in 2013/2014 is about accommodating usage patterns that many, many users have already adopted and are intimately familiar with. This is okay, but you’ll need to play by the rules already established by thousands of other companies and organizations that have already built mobile apps.  Don’t play and it could mean lost customers and slower business growth.

Myth #1 – Mobile, we don’t need no stinkin’ mobile. The sheer number of mobile devices in circulation is a hard, cold fact. There’s hundreds of millions of them. And rest assured these devices are well loved and used constantly 24 x 7 by their adoring owners. Smartphone and tablet sales worldwide have finally started to outnumber desktop sales. Along with the shift to mobile, the use cases have changed in a significant way. Think about this: desktop use cases only apply when you are sitting at your desk or crack open a laptop. In comparison, mobile devices go with us wherever we go and we can access them anytime and almost anywhere: such as standing in line at the grocery store, waiting for dinner at a restaurant, getting real-time driving directions and the list goes on and on. The very nature of having a device with you all the time, even when you go to bed, lends to its ease-of-access.

Myth #2 – Squeeze existing content onto a smaller screen. Don’t do it. It can lead to awful and sometimes nearly unusable navigation and surfing experiences. Users who spend many hours a day looking at their mobile devices and visiting dozens or hundreds of sites and apps that are mobile-ready will absolutely expect your content to be mobile compliant.  For this reason major phone OS vendors have spent a lot of time and money to publish user interface guidelines.

Myth #3 – Continue to use long development cycles. The mobile world changes fast. Prototyping should occur in hours, days or weeks rather than months or years. Full release cycles are  often measured in months. To get an idea of the pace of change check out how fast updates occur to the Android operating system. I’ve gotten feedback on some companies with mobile development cycles being planned for up to 1.5 years from design to delivery of v1.0. In today’s fast paced world that can be a sure bet for problems and increased risk of project failure.

Myth #4 – Recreate complex workflows on smaller screens. Mobile device workflows call for simplified, intuitive workflows with fewer steps. If you have what I’ll call an enterprise web app with dozens of menus and pullouts, pulldowns and multiple pages then you’ll need to do some homework along side a good user interface designer to figure out how to make it work on mobile. Chances are your app will have to be sliced and diced into smaller and more digestible chunks.

Myth #5 – Reuse existing security measures on mobile. Mobile security is vastly different than desktop security and applying desktop security patterns to mobile can be a recipe for disaster.  People carry their devices everywhere and they tend to download many different apps, and some people don’t even use their screen lock. We’ve all heard stories of devices being left unattended in public places or left behind at airport security screening.  So, there are many more ways for potentially serious security breaches to happen via mobile devices than your typical laptop.

Myth #6 – Users won’t like change. If you have a public facing web site today that’s not mobile compliant, chances are you’ll have a significant portion of your mobile users who aren’t happy. The best way to find out: survey. Ask your users what they think…don’t leave it to guesswork and opinions. Get the facts from the people who matter most: your customers. And, I’m going to go out on a limb and say that the majority of users would jump at the chance to use a mobile version of your website.

References

iOS Version History
Android Version History
WindowsPhone Version History
iOS User Interface Guidelines
Andriod User Interface Guidelines

Tags: , , ,
Posted in Mobile | No Comments »

Okay, I expected a battery life boost when I got my LG Nexus 4 (16GB), but what I got blew me away. When I finally got the phone last week as a replacement to my battery hogging Samsung S3 I didn’t really expect much in terms of battery life.

I immediately installed three apps that I use a lot and that draw some amount of standby power: corporate email, a second email account and Twitter.  Then I got a prompt to upgrade to Android v4.3 (thanks LG!) so I immediately installed the update. I fully expected to get 10 to 12 hours of use before the battery approached rock bottom. Well was I wrong…way wrong…because at the 32 hour mark (1 day 8 hours) I still had 42% battery left! See the screenshot at the bottom of the page. I’ve also seen other reports that 4.3, by itself, added an amazing boost to battery life.

Note, I did the exact same test on my S3 when it was brand new and it lasted almost 12 hours before it started throwing low power warnings. That’s pretty much been my general experience with the eight other various Androids that I’ve had since v1.5. The results from the Nexus 4 blew that out of the water. I understand this is a brand new phone with very few apps on it. And as I add other apps that eat power in stand-by I’ll fully expect to see a drop off in battery life, especially as the battery gets older and more discharge/recharge cycles on it.

I also wanted to explain my usage pattern for the phone. It is what I’ll refer to as light- to medium-duty. What I mean by that is I would check email, news and twitter every two to three hours. This would consist of browsing on the phone for roughly 7 – 10 minutes at a time in short bursts throughout the day. I very much use it as a business and Android dev phone.

My main suspicion is that the WXGA IPS screen combined with the Snapdragon processor and Android 4.3 is dramatically more power efficient than the Super AMOLED screen on the S3 running Android 4.1.2 with a Samsung Exynos 4 quadcore. I’ll also point out that the screens are roughly the same size, if you were thinking maybe the Nexus 4 had a smaller screen and that’s what saved on power then think again. In fact, the Nexus has a slightly higher pixel density:

Samsung Galaxy S3 – 720 x 1280, 4.8 inches (~306 ppi pixel)

Nexus 4 – 768 x 1280, 4.7 inches (~320 ppi)

My point is that when jumping between previous major Android versions in the past we never saw battery life improvements even close to this. And from a hardware perspective, my S3 and all of my other pre-4.2 Android’s had screens that were major gas hogs. The screens on those phones were always at the top of the list on the Android battery consumption monitor as the number one energy consumer.

Conclusion. Whoa! I’ve been harping on Android’s miserable battery life for a long time, and now the Android team along with their hardware manufacturing friends may have finally broken the trend. Time will tell as I continue to use the phone and load up on apps if 4.3′s battery life improvements continue to hold up under pressure.

Android battery at 32 hours

Tags: , , , , , ,
Posted in Android, Mobile | 2 Comments »

There is no doubt that consumers benefit from today’s unprecedented rapid technological innovation in mobile and web. But, there are costs that business incur as a result.

Here’s an overview of some of the costs that you should take into account when building budgets as well as mobile and web strategies. Some have argued that the trend of B.Y.O.D., or Bring Your Own Device, has mitigated some costs to corporations and organizations. That may be true, but after reading this you will probably agree that the costs listed below reach beyond the cost of the actual device. These are all things you have to take into account to stay competitive in today’s hard charging environment.

Hardware turnover.  The advantage here goes to iOS devices. Android devices can become obsolete within six months because cell providers are allowed to provide phones and tablets with customized versions of the Android OS. They essentially lock you into a forced hardware upgrade because you’ll only get one or two minor OS upgrades per device. Your company will have to balance that software it can run on various device operating system versions. Whereas iOS devices, on the other hand, get access to the latest updates. Also, like the traditional PC upgrade path, with mobile devices you may have to upgrade to gain access to greater memory or CPU capabilities.

Code updates. You’ll spend a significant amount of time keeping up with the latest capabilities. It takes time to learn how best to adapt to the latest coding patterns, UI design patterns, and technological advancements.

Reverse compatibility. Some business have a requirement to maintain their code on older versions of browsers and operating systems.  The further back you have to support OS versions the larger the support costs. The larger the gap between the latest versions of SDKs, APIs, devices and browsers and legacy versions the greater the cost.

Security. It can be very challenging to secure smartphones and tablets from physical intrusions and viruses. These breaches can give criminals access to your internal systems. Tracking down security leaks and fixing breaches can be very expensive and time consuming.

Replacement devices. You’ll need to decide whether or not to carry insurance on each device, or take the chance that a device will never get dropped, broken or stolen. Replacement costs are extremely expensive if you have no warranty and no option from the cellular carrier to get a subsidized upgrade.

Poor connectivity. This may seem like an odd cost to list, but poor connectivity can cripple the productivity of a remote workforce. The more reliant an organization becomes on internet connections, especially for real-time systems, the greater the cost that can be incurred when users encounter connectivity problems. Poor connectivity means slow, intermittent or a non-existent internet connection.

Cellular data costs. Another byproduct of being increasingly mobile is dealing with how your architecture handles data transactions between clients and servers. Chatty applications, or applications that move a lot of data back and forth, and heavy web pages, or web pages that are physically large when loaded into a browser, can result in significant internet and cellular data charges.  For example, if your application is 3 MBs and it is accessed 1000 times per day by your workforce, that adds up to 3 GBs of data usage per day.

Tags: , , ,
Posted in Internet, Mobile | No Comments »

Where Part 1 focused on non-GPS enabled devices, Part 2 is totally focused on mobile web geolocation. The great news is that the usage of HTML5 location services along-side the fact that there is a GPS chipset in most, if not all, modern smartphones and tablets dramatically improves the chances of getting an accurate location. And, besides that fact — mobile geolocation is simply a lot of fun to work with.

I also want to point out that there are an increasing number of really good blog posts covering the topic of “how to use” the API that look at the nitty-gritty of how the code works. This post is different in that I’ve tried to focus on “how to build successful applications” with the API, and how to get the most out of the API so that you can successfully implement your unique requirements.

What’s different about desktop vs. mobile HTML5 Geolocation? With mobile you can access the GPS if it’s available. It’s important to note that in order to access a device GPS you have to set the optional enableHighAccuracy property in your code. Contrary to what is shown in some samples on the internet, you can use this property with both the getCurrentPosition() and watchPosition() functions.

//One time snapshot
navigator.geolocation.getCurrentPosition(
     processGeolocation,
     // Optional settings below
     geolocationError,
     {
         timeout: 0,
         enableHighAccuracy: true,
         maximumAge: Infinity
     }
);

//Tracking users position
watchId = navigator.geolocation.watchPosition(
     processGeolocation,
     // Optional settings below
     geolocationError,
     {
         timeout: 0,
         enableHighAccuracy: true,
         maximumAge: Infinity
     }
);

How accurate is it??? This is the million dollar question, right? When using enableHighAccuracy() on a phone where all the appropriate permissions have been selected and granted, I’ve typically seen accuracy readings as low as 3 meters (~10 feet) that were obtained within 10 – 30 seconds of kicking off the geolocation functionality. I’d consider that excellent for most consumer and retail applications. You should be aware that like any location-based functionality you will get spurious (abnormal) results that fall way outside the norm, and sometimes these results are wildly wrong.

I’ve seen claims that using the enableHighAccuracy() property slows down the phones ability to deliver a location. I’m going to argue that those claims are misleading. It is true that the GPS, itself, can take a significant amount of time to warm up and start delivering high accuracy results. For an in-depth look at that topic see my post on the Six Most Common Use Cases for Android GPS. However, there are conditions where simply enabling the enableHighAccuracy() property doesn’t affect the speed in which you can get the initial result. More on these topics below.

What is the best way to try out various configuration scenarios? I’ve built an HTML5 Geolocation Testing tool that can be used in browser, or it can be repurposed to work in PhoneGap or Titanium. It is a jQuery-based mobile application that includes a map and settings view were you can adjust all the different properties and try out different configuration scenarios. It’s a work-in-progress so I welcome suggestions and pull requests.

 Why HTML5 Geolocation rather than native? Applications using HTML5 Geolocation typically have slightly different requirements than native GPS-based applications. Each platform has its advantages and disadvantages and it all comes down to your requirements, budget, timeframes and skill sets:

  • Ability to re-use existing JavaScript and HTML5 skills to build a high-accuracy mobile application.
  • Don’t have access to native platform developers or skillsets on Android, iPhone and/or Windows Phone.
  • Need a cross-platform stand-alone web app, or a web app that has been repurposed to work with PhoneGap or Titanium.
  • Quickly locate the user/consumer within a reasonable expectation of accuracy.
  • Typically it is a non-commercial, consumer grade application that does not have extremely high accuracy requirements (e.g. < 1 meter).

How fast can I get an initial location result? The answer is very fast, potentially within a few seconds, given the following scenarios:

  • If there was a cached GPS or Network location stored on the phone. The GPS location is, of course, from the GPS chipset. The Network location comes from your wireless carrier and is dependent on your phone and their capabilities.
  • How the timeout and maximumAge properties are set. If you set timeout = 0 and maximumAge = Infinity it will force the application to grab any cached location, if one is available. Other settings may result in delays.
  • If the phone or tablet has decent internet connectivity and Wifi enabled.
  • If the device is in an urban area with many wifi nodes broadcasting their SSIDs nearby.
  • The device has a clear and uninterrupted view of the sky. GPS’s listen for a very weak signal from multiple satellites. These signals can be partially or completely blocked by buildings, thick foliage, vehicle roofs, etc.

 How accurate is the initial location result? Hah, you might have guessed I’d say that it depends.  When you first kick off a geolocation request, accuracy does depend on a number of different factors that are mentioned above. And it’s safe to say that, in the vast majority of cases, the first location is not the most accurate and typically not the most dependable. If you want the fastest, most accurate location possible then you will most likely need to either do multiple snapshots, or use watchLocation until your desired level of accuracy is met. It’s important to note because I’ve been asked about this many times, you cannot expect the GPS, itself, to have enough time to lock onto a satellite and deliver a fast, accurate initial location. It may take dozens of seconds or even minutes. Yep, it’s true. Factors that affect initial location accuracy include:

  • Cached locations – how recently the user accessed location functionality. For example, applications like Facebook typically grab a location when you open the app. So frequent users of social media are more likely to have a fresh, cached location that non-social media users. If you are targeting business travelers, the cached location might the last city before they got on a plane. Or, it could be your home neighborhood and not where you work or go to games.
  • Wifi turned “on”. If the Wifi is turned on then the device can access the location service and there is a much greater chance that the initial result is fairly accurate. If you didn’t have a chance to read Part 1, when the Wifi is on your browser gathers local Wifi node information from your Wifi card, and it can use that information in a location service provider request over the internet to try and triangulate your position. Typically this means your initial location can be within a block or two of the actual position. Also, it is possible if Wifi is turned on that you can get a significantly more accurate initial location than if you were using GPS by itself with no Wifi or internet.
  • Internet connectivity strength. If you have a poor internet connection and no Wifi, then the browser’s requests to the location service can be delayed, blocked or even interrupted.
  • No VPN. Take note commercial application developers: as mentioned in Part 1, if VPN software is in use it can wildly affect accuracy and even place you in another State (or Country).

Can I use HTML5 Geolocation for mobile tracking? Yes, with caveats. Typically HTML5 tracking applications are built inside a native wrapper framework such as PhoneGap or Titanium. There are several immediate problems with stand-alone, browser-only HTML5 tracking applications. First, there is no built-in functionality to keep the screen from going to sleep. Second, when the screen goes to sleep the HTML5 Geolocation functionality also goes to sleep. Native-based tracking applications can work around these limitations and listen passively in the background when they are minimized. Third, you have little control over the GPS settings to help management battery consumption.

Can I use HTML5 Geolocation offline? Yes! If there is no cellular connection or Wifi available, then HTML5 Geolocation can still access cached locations and real-time GPS information. This is vastly different from what was discussed in Part 1 as related to applications targeted at laptops, desktops and tablets that may or may not have GPS. If a device does not have a built-in or externally available GPS then your offline application will not work.

Handling abnormal location results. Your application will occasionally encounter widely inaccurate results and you need to handle these gracefully for the best user experience possible. My recommendation is to check the timestamps and distance traveled between the current geolocation object and the previous one. If the distance or speed seems excessive then you’ll need to reject the result. In the reference section below is a link to more information on calculating the distance between two points containing latitude and longitude. As an example, see the attached screenshot with the spurious results indicated by red circles. Also note in the screenshot the accuracy level was 3 meters, so it’s important to understand that even at high accuracy levels you still need to very that each location meets your minimum requirements. This way your results will always look polished and professional to the end user.

Spurious results

What are some of the downsides of using HTML5 Geolocation versus native? The bottom line is that for simple location gathering and basic tracking HTML5 Geolocation is just fine. This should meet the requirements for most consumer applications. For anything more complex than that you should consider looking at going native.

  • It may not work on older phones and older browsers (depending on your definition of old). See below in the references section for a link to a fallback library to handle these situations.
  • HMTL5 Geolocation offers significantly less control over GPS settings. This can have an unacceptable impact on more complex applications.  Because of this, I also suggest that HTML5 Geolocation is not suitable for long-running tracking applications.
  • Battery life management. This is a direct result of bullet #2. It’s more challenging to manage battery life with HTML5 Geolocatoin if your requirements call for continuous use of the GPS.  Your control is very limited with respect to these two properties: timeout and maximumAge.
  • Cannot use it when the application is minimized. If your requirements calls for the ability to passively receive locations while in a minimized state then, as mentioned earlier, you will have to go native.
  • Very little control over how often you want location updates. You’ll need to do a bunch of custom coding to emulate what is already built into native application APIs. For example, the native Android API offers very detailed control over what type of geolocation data you can get access to, how you can access it and how often. Read more on that topic in my post on How Accurate is Android GPS Part 1 – Understanding Location Data and also take a look at Android’s LocationManager Class.

References

W3C Geolocation API Specification 

HTML5 Geolocation Test Tool

Mozilla – Using Geolocation

Calculating distance between two points.

Geolocation fallback library for older browsers

Tags: , , , , , , , ,
Posted in Browsers, HTML5, Mobile | 17 Comments »