Archive

Android: Working with Eclipse’s quirks

January 21st, 2014


The Problem

One of the most annoying quirks for Eclipse when working with Android emulators (Android Virtual Devices – AVDs) is that sometimes once you’ve launched an AVD (which can take several minutes), it can lose connection with the emulator. This means that when you try to launch your app on the running emulator, it cannot find the app, and will not output any logs to Eclipse. Sometimes restarting Eclipse or the AVD helps, sometimes it doesn’t.

The Solution

To fix this, we can restart the Android Debugging Bridge (adb), which connects with the AVD, even whilst the AVD is running.

In the console, type:

adb kill-server
This will kill the adb server.

Then restart it:

adb start-server

Then try running your app again – it should find it then connect in Eclipse, and give you the logcat / console output.

Major issues on iOS7 Safari and Web Apps

September 27th, 2013


Horrible issues facing developers for iOS7 Safari and Web apps (e.g. home screen apps cannot use alert, confirm, etc).

See them documented here: http://www.mobilexweb.com/blog/safari-ios7-html5-problems-apis-review

Native App vs Web App – Which should you choose?

October 15th, 2012


As time goes on, the number of mobile devices that are used to access the web just keeps on growing.  It is showing no sign of slowing down.

With this, we are seeing more and more applications being developed for the now vast array of devices available to us, whether that’s on a mobile phone or a tablet – the list goes on!

Say you get that ‘big idea’ and you think that you can make an app for it, where do you start?  The first thing you need to consider is what sort of app you would like it to be, a native application, or a web application (or both of course!).  In this article I’ll be taking a look at the differences between the two and also their strengths and weaknesses.  Hopefully it will help you choose the correct path on your app development journey with us.

Read

Large Application icons for iPhone & iPad apps

June 19th, 2012


Please see the following link for a summary of the new requirements for application icons for all apps submitted from July 2012 onwards:

http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/IconsImages/IconsImages.html

- the key one is that now an additional application icon of 1024×1024 is required. The icon is for the app on the App Store.

Mobile Applications vs Mobile websites

December 5th, 2011


 

A common request from clients is for a mobile application to partner their website (“I’d like an iPhone/iPad app”). This is not a bad request in itself, but I often will discuss with them their reasons for wanting an app, so that they are not spending unnecessary budget on development. Quite often, a mobile website will do the same job or even a better job, than an application.

Strengths and Weaknesses

It’s important to consider the strengths of a mobile application versus a mobile website:

  • A mobile app can access all/most hardware capabilities (e.g. camera, geo location, offline data storage, compass, standard interface elements like tabs and list views). A mobile app can be hardware optimised.
  • A mobile website can access some but not all hardware capabilities (e.g. geo location, offline data storage). A mobile website is limited to the browser’s capabilities and Javascript engine speed, but there is a lot that a browser can do.

 

  • A mobile app can generate income via the App Store or Android Marketplace. This means that the developer doesn’t have to add a sales mechanism (e.g. merchant banking, PayPal, etc).
  • A mobile website can generate income only through online payment engines (e.g. PayPal, etc).

 

  • A mobile app (on iPhone/iPad) can only sell subscriptions to content through the App Store, giving 30% to Apple. Apple owns the relationship with the consumer, rather than the client.
  • A mobile website can completely own the relationship with the client, which can be leveraged for other sales opportunities.

 

  • A mobile app can be launched via a URL, but managing this URL cross-device is challenging. This is an issue when sending emails with links to content.
  • A mobile website can be integrated with an email strategy or other linking. A mobile website URL is cross-browser compatible.
  • A mobile app has to be found via the App Store / Android Marketplace – searching for and getting found by users is haphazard to say the least. A mobile app launch should be accompanied by multiple marketing strategies including the web, to point users to the App Store / Android Marketplace.
  • A mobile website can be found by Google, and standard web marketing strategies and SEO can be used to bring users to your website. In addition, existing users of your website do not have to download a separate application; they can instead be switched automatically to your mobile website and brought online to the mobile experience.

Case Study: The Financial Times

A good example of an organisation choosing a mobile website over a mobile application is the Financial Times. They chose to remove all their mobile applications from the App Store  / Android MarketPlace, and developed a feature rich mobile website. See the following article: http://www.mobile-ent.biz/news/read/ft-s-html5-app-has-1m-users/016218. Some of the standout figures include:

  • 20% of all online page views are via the mobile website
  • 15% of all new digital subscriptions come via the mobile website.

The lesson is that we should consider the requirements of the mobile experience for the user, and then choose a platform (website or application) following this. Don’t assume that an application is always the solution.

Why Responsive Design Actually Begins on the Server

December 1st, 2011


There is a very interesting presentation at http://www.slideshare.net/yiibu/adaptation-why-responsive-design-actually-begins-on-the-server . It covers the challenges in responsive mobile site creation, and proposes a hybrid solution of device profiles to solve it.

The first half of the presentation is worth showing anyone who does not understand the challenge of developing a mobile website that works well on multiple mobile devices, not just on the latest and greatest iPhone / Samsung / HTC.

It’s strongest point is that many people (especially in this current financial climate) will not have the latest leading edge device. In fact, your cutting edge, state of the art device from 2 years ago (read iPhone 3/3G) is now old and destined for the mobile device rubbish heap. However many people will not automatically upgrade, but will keep them, and thus there is a great proliferation of devices which don’t support the latest HTML5, slower Javascript, etc.

Added to this is that the word ‘smartphone’ retains a nebulous definition, and in fact today’s ‘cheap’ devices contain most of the features that a smartphone has (e.g. touch screen, browser), however their ability to serve the web may not be as perfect as Apple’s Mobile Safari.

This is the reason that content adaptation has had a number of solutions, via examples such responsive design, server-side detection and adaption, etc.

The solution proposed in this system is not a simple solution. It proposes an aggregation of device information (e.g. from DeviceAtlas) on top of a default device profile, stored in cookies, sent via Javascript to the server to analyse. To implement it for a client, I for one would hope to see a library to help achieve this without the larger development cost, so I will be watching closely.

There are also some interesting suggestions at the end of the presentation about some potential options for the future, e.g. changing the <img> from having one source file to having multiple source files (similar to the way the <video> tag is currently done). I would be interested in this option, however the reality is that the HTML change process is long and tortuous and thus I won’t be holding my breath.


Switch to mobile version