Entries Tagged as 'Mobile devices'

Letters In Place of Numbers in Phone Number Links on Mobile Phones

Miscellaneous , Mobile devices 6 Comments »

Part of an upcoming project involves displaying office phone numbers on a web page such that, if the page is being viewed on a smartphone, tapping on the number pulls up the phone's dialing program with the number filled in and the user just needs to start the call.

Some of the phone numbers in question use letters in place of numbers (like "1-800-555-CFML" as an example) and I wondered if such numbers would work.

The answer is "probably not," as it's not something supported in the spec (the spec being RFC3966).  Tried it on my Galaxy Nexus anyway: no dice.  So I'll have to convert any such letters to their numerical equivalent

Some other things I learned today:

  • Per the W3C recommendation regarding "click-to-call" links, you should always include the "+" sign in front of the number to support international callers ("+1-800-555-CFML").
  • You can also use "." as a separator instead of a "-", and you can get away with using both types of separators in the same number.

One Android App, Two Different Markets (Nook vs. Amazon)

Android , Android development , Mobile devices 2 Comments »

Facts:

  • My Quick Shopper app is a fairly simple app for creating a current shopping list from reusable items I designed based on my own shopping list habits.  It is currently optimized for 7-inch tablets.
  • It became available on the Barnes and Noble Nook app market on October 28th at a price of $1.  On the Nook app market, the search term "shopping" returns 4 results for apps focused on shopping lists or the act of shopping.
  • It became available on the Amazon App Store around November 26th, also at a price of $1.  In the Amazon App Store, the search term "shopping" returns over 400 results.
  • If Quick Shopper was highlighted or advertised in some way on either market, I am unaware of it.
  • The sales numbers for the first 30 days in each app market:
    • Amazon - 4 sales
    • Nook - 478 sales
  • 478 > 4 (by a lot).
  • I know of at least one other developer who sees higher sales of his same app in the Nook market over the Amazon market.

Thoughts:

The most likely cause of the vast difference in sales is that my app has very little competition in the Nook market, while in the Amazon App Store it's simply lost in a sea of similar apps, some of which are free.

But since I'm not the only app developer who's seeing more success in the Nook market than they are in the Amazon App Store, there may be other factors at work.  The Nook app market exists solely to provide apps for the Nook Color and the newer Nook Tablet:  anyone using that market knows that any app they see is (supposedly) designed for use on those tablets.  The Amazon App Store on the other hand caters to Android phones and standard Android tablets in addition to Amazon's own Kindle Fire, so perhaps the phone-targeted apps get more of the attention and the ratings because of the wider install base.

It may also have something to do with the buying habits of the different audiences.  I attended a web-based presentation given by a Nook evangelist who said that their studies showed Nook owners were far more willing to pay for apps than the average Android user (or something to that effect; I forget exactly what the slide said).  The sales numbers I've seen would seem to support that claim.

Of course, this is just my experience. If other developers are seeing similar results or perhaps even the opposite, I'd like to hear about it.

An Overview of buzztouch, A Mobile App CMS for Non-Programmers

Miscellaneous , Mobile devices , Technology 3 Comments »

The other day I stumbled on a Make Use Of article about buzztouch, a "iPhone, iPad, Android app builder and content management system."  Since we're researching options for creating cross-platform mobile applications, and the article indictated that it was worth checking out, I decided to sign up and give buzztouch a spin.

buzztouch is designed to let non-programmers build a mobile app on the buzztouch website using a collection of web-based forms.  The app-building interface prompts you to create certain items, like a launcher icon for the app, a banner image for the home screen, and an "info" page for the app, but you choose what other content you wish to provide from a drop-down list of different components.  One component lets you create a screen of formatted text using CKEditor, while another lets you create an app screen using HTML, CSS, and Javascript.  There are components for pulling in remote content such as web pages, YouTube pages, streaming audio and video files, and RSS feeds.  One component lets you pinpoint one or more locations on a Google Map with brief location information that a user of the app can then use to get driving directions to those locations from their current position.  Even though I was casually playing with the system, I was able to create an app using several of these components in under two hours.

Once you've created the app, you can then download the native source code for the app:  you're provided with separated source code downloads for IOS and for Android.  The source code comes in a .zip file, which also contains a readme file with instructions on how to compile the source code for that particular platform and create the native app.  It only took me a few minutes to create an Android app from the source code, and it only took me that long because I had to provide a Google Maps API key to enable the mapping component I'd added (the readme provided exact instructions on the changes I need to make it the code to use the key).  I had my IOS developer colleague compile the IOS version of the app, and it was also smooth sailing for him.  The resulting app on the Android platform looked a little rough simply because of the generic design elements, but the IOS version looked pitch-perfect.

The first time you access any component or screen in the mobile app, there is a pause as the app retrieves the content or content instructions from buzztouch then caches it for local use.  This is where the content management system aspect of buzztouch kicks in:  any changes you make to the app on the buzztouch site get pushed to (or pulled by, not sure which) the mobile app.  So the app owner doesn't need to recompile and update the app through the App Store or the Android Market in order to make content changes.  If the mobile device doesn't have a network connection, then the cached content is used.

So what's my overall take on buzztouch?  I think that if you need to build a mostly informational mobile app, something that serves the same purpose as a mobile-optimized website, then buzztouch is a compelling option because of how easy it is to create the app and then update the content.  Even if your long-term strategy is to redesign an existing "desktop"-optimized website to be mobile-friendly as well, a buzztouch app could fill the void until that goal was reached.

If you need to build a mobile app that's more interactive, one where the user can send and receive custom data, then buzztouch is at best an incomplete solution.  There are no buzztouch components for collecting data (though the app itself will capture GPS info from the device in order to map where the app has been used, which is both useful and slightly disturbing), but you could probably use the Custom HTML component to create a web form that transmitted data via a regular form submit or via AJAX.  And there are as yet no components that let you access device-specific functions like the camera or accelerometer.

On the other hand, if you are capable of doing some IOS or Android coding, the native code provided by buzztouch could serve as a starting point for adding additional functionality:  the buzztouch folks seem to be open to folks using the generated code to advance their learning of native app programming.

So overall, I'm impressed with what buzztouch has done so far with the direction they've taken, and I hope they continue to improve on the platform.

New Android App: MyReminders

Android , Android development , Mobile devices 11 Comments »

When I created my first Android app, NoteToSelf, I had always intended to release a "deluxe" version with additional features.  Even though this app is essentially that deluxe version, I felt it needed a new name to reflect its most notable new feature (reminder alarms).

So this incarnation of the app comes with the following features:

  • It allows you to dictate your reminder instead of typing it via Google's speech transcription service. All you need to dictate your reminder is a network connection (celluar or WiFi) and no concerns about talking to your phone in public.

  • It gives you the choice between three different home screen widgets that let you cycle through all of your reminders and add or edit reminders via the widget.

  • It lets you schedule an alarm for those reminders that are time-sensitive. You can use the settings in the app to determine how the alarms should notify you (by default, the alarm will cause the phone to vibrate and the notification light to blink).

You can read more about the app and view several screenshots at the following URL:

http://www.thoughtdelimited.org/android/myreminders/

Now...I did decide to charge $1 for this app in the Android Market, because I did put a lot of work into it and I think it's certainly worth that much given the functionality it provides.  However, if you're a contributing member of the ColdFusion/CFML programming community (someone who regularly shares their knowledge or their code to help others) and you have an Android phone that allows you to install non-Market applications, send me an e-mail and I'll send you the install file so you can have the app for free.

Saw a Windows Phone 7 Prototype In Action

Miscellaneous , Mobile devices 1 Comment »

Just got back from the first Washington DC jQuery UI Meetup (more on that in a later blog post). One of the co-presenters was a Microsoft Developer Evangelist who happened to have on him a prototype Windows Phone 7 device and was willing to demonstrate it for anyone who was interested. So I got to take a look at it and wanted to share a bit of what I saw while the memory is still fresh.

If you haven't seen any of the photos or videos of what Windows Phone 7 looks like (check out Engadget), the UI is very different from that of the iPhone or Android. Instead of icons and distinct applications, you have tiles that you tap to enter certain "hubs", and within these hubs can be added app-like functionality. For example, the hub concerning photos not only serves as a photo gallery for the photos stored on the phone, but also provides the functionality for uploading your photos to Flickr or Facebook or for viewing photos in your friends' Facebook albums. Another distinct difference is that the UI menus can span across multiple horizontal screens, so sometimes you'll see text cut off on the right side indicating there's more going on just off to the right. 

I knew most of that prior to seeing the actual phone, but I was curious to see how it actually worked in practice. It actually looked kinda cool: the scrolling and screen transistions were smooth, and the removal of the need to fit text into the width of the handheld screen allowed Microsoft to use bigger font sizes for the text, making the screen very readable even from a few feet away.

But in other ways, the UI was more subtle: it has a celluar radio strength indicator at the top of the screen like the iPhone and Android phones do, but the text was small and the background was transparent, letting the wallpaper image show through underneath. And as we waited to see new Facebook updates from his friends (Facebook functionality is integrated into the OS), he pointed out the marching horizontal line of green dots that appeared at the very top of the screen that indicated that data was being updated. It was barely noticeable, but very unobtrusive.

The interesting thing I found about the "hubs" concept was that each hub area was distinctive (different background, different text color), which really emphasized the idea that you were in a different area or aspect of the phone, not just a standalone app. And he wasn't switching from one app to another to do things: he was navigating around or deeper into the current hub to access certain functionality.

Another attendee asked him what the platform would be for developing apps for Windows Phone 7, and he told us that developers could build apps for these phones using either XNA (which I'm unfamiliar with and too tired to look up right now) or Silverlight. Given the struggle Microsoft has had in promoting Silverlight as a competitor to Adobe Flash, it'll be interesting to see if the ability to develop mobile phone applications with Silverlight will further Silverlight adoption. I should also note that earlier in the conversation, he'd mentioned that the first version of Windows Phone 7 wouldn't support browser-based Silverlight or Flash (simply because there wasn't time to put that into the first release), so I took that as a sign that Microsoft plans to allow Flash (at least browser-based Flash) on these devices.

I think that about covers it. While I personally plan on remaining an Android user, I do think Microsoft's doing something interesting here, and I'm curious to see how it plays out.