Category Archives: Mobile

Android Sync Adapter or Direct API Access

I am starting to develop a new Android application and am torn between using Androids Sync Adapter or just calling the API directly like I did with pervious applications. I can see benefits to each. I see some applications use Sync Adapters while others seem just as fast and are not using Sync adapters. It doesn’t seem like Android really has a standard of which one to choose and which situation you should choose one over the other. It seemed from my readings that Sync Adapters are the new standard but I just don’t see many applications using them. I see benefits and consequences to using each. I am having trouble choosing as I want this application to do everything to the Android standard. I see a lot of benefits to using direct API access again.

First I have been using direct API access for some years now so for me I already know what I need to do to connect to the API. I already have the code needed to perform json encoding tasks. Another benefits as I never have to worry about the data getting out of sync. The process will happen as the user saves the form or deletes the record. So the web server and application will always have the same data along with primary keys. Also if the user looses their device or gets a new device they don’t have to worry about the syncing not working. Their data is always safe on the server. To me it just feels a little more safe as I know the users data is up on the server if they get the saved response back. Otherwise they will get an error right away of errors they need to fix.

There are also some consequences to using direct API access. The biggest one is that it requires the user to always have a network connection while using the application. Some of that can be minimized by caching though. I tend to think phone networks are getting faster and have more coverage but there are some users that are unable to connect for some reason. Even with WiFi hotspots being all around again some users are unable to find them when using the application. This leave a negative impact to the user as they find the application useless without that connection. This makes it hard to complete with applications that do not require a network connection to work. Even though the data is not being sync to the cloud and therefore could be lost easily. The end user does not see this benefit in some cases.

There are benefits to going with the sync adapter method from my initial research. Which to be honest with you wasn’t a ton maybe three or four hours reading through the Android documentation. The first benefits with the sync adapter as you don’t have to worry about the network connection at all. The sync adapter handles that for you. It will check if the network is available and if it’s not it will wait tell it’s available This will give your users an offline mode while still getting the data backed up when it’s possible. Also this is built into the Android framework so it is relatively easy to learn and use. There are plenty of examples of how to use it on the web.

There are also some consequences to using the sync adapter. The first one that I see is you have to create a local schema using SQLLite that basically mirrors what your web server is doing. So every time you make a database change on your server you have to make that same change to the Android application. Also any business logic that your web server is performing has to be done the same way on the Android application. Since the sync adapter may not run the second the users submits the data you need to have your Android application verify that the data being saved will save on the web server. You could get around this by checking that the syncing process finishing successfully and if it doesn’t pass the failure onto the user at that time. The problem I see with that is it could end up frustrating the user. They might not remember exactly what they intended to do at the time. Depending on how long their device was offline for. It could be a day it could be weeks who knows. So maybe they entered a number incorrectly but have since forgotten what it was. Seems like you would have to be repeating business logic across the environments.

These are the thoughts that have going through my mind as I am starting this new application. According to Google using the sync adapter is considered the best approach. At least it seemed that way although the documentation did not say so. An example that I found on my device that uses sync adapters is Dropbox. I am not sure that my application would need such a thing. I almost feel like sync adapters are made for applications that are always looking to get data like an email client or Dropbox. You can setup syncing times or intervals. Is there a better way of getting data in and out other than these two options? Also if you go the direct API route can you cache it locally still and sync the next time the application starts up?

JQuery Mobile Overview

I recently added a mobile version of my website  wallproductions. I am using the Yii framework so telling which to render mobile vs desktop was pretty straight forward. The hard part was converting the current layout to be mobile friendly. Before I started manipulating my views to be mobile friendly I decided to do some research to see if a framework for this type of thing already existed. Lucky enough I came across JQuery Mobile which so far has been great. JQuery mobile provides a lot of the core structure you need to get started.

The first thing I did was added in a menu. For that I used  jquery-mobile-slide-menu which is an add-on to JQuery mobile. I find it to be easy enough to use and I can easily understand everything it’s doing. I believe there is a built it menu too but I think this one added a couple of smaller enhancements on. Which I found to be very useful. The next thing I did as I started to add in links for the new mobile pages. The routing was not changing so that was another simple step. There was one issue I ran into while adding these links. I noticed that my pages javascript was loading the on page load event. I did some research and found out that in jquery mobile that event won’t fire. At that point I had a choice to rewrite all of my existing javascript to use that new method or not use ajax links. I decided to go down the road of disabling ajax links and since then I have not had issues with my existing javascript. Here is the solution to turn off ajax links so everything you already have work as you would expect.

$.mobile.ajaxEnabled = false;

Another road that I went down before completely disabling the ajax links was to refresh the ajax page on each load. That seemed to work well in most cases but I had some that required a full DOM load. If you want to try to reload the DOMeach time and see if it works you for you then you can implement some javascript like this. This will tell JQuery that it needs to do a complete page refresh with each link click. You can enhance to support other elements like buttons to.


$('a').live('click', function(e) {

var url = $(this).attr('href');

if (url != '#' && url != '' && url != '/#') {

$.mobile.changePage( url, { reload: true, transition: "none"});

}

});

Google Nexus Lineup

I recently read some articles saying that Google may discontinue their Nexus lineup. As an Android user I see this as a huge mistake. Before the Nexus lineup Android was talked about but not always in a good way. A lot of users that I would talk to would say well the device I have sucks. It’s slow or the interface is confusing. When the Nexus lineup came out everybody had a pure Google phone to go to. I could just tell them well you should probably get the latest Nexus device. The reason why I would say that as I knew that you would get a pure Android with a Nexus device. Here is an article that I was reading Rumor: Google Nexus Branding to End with details on why these rumors are happening. I sure hope that the Nexus lineup doesn’t go away.

The first reason why I love the Nexus lineup as the pricing. The price for the device is usually a couple hundred dollars less than comparable devices. The reason why this can happen as Google doesn’t make much if any profit off of their Nexus series. The intention is to get their devices out at a reasonable price without a contract. This will allow your average person to own a device without breaking the bank.This is one reason why they are talking about ending the brand though. Since Google makes hardly any money off of it they want to get out of the business. I feel that if they would just raise the price maybe one hundred dollars more per device they would still have people buying them. Then at the same time they may not end of loosing money with the series. When you think about the competition with Apple vs Android you really compare the Nexus series not say HTC or Samsung.

The second reason why I love the Nexus lineup as you get pure Google. For example if you buy any HTC device you have to use their HTC sense interface. At least that is the default of course there is way’s to change this but you could void your warranty. Also devices outside the Nexus lineup come with a lot of bloatware. For example most HTC devices come stocked with Facebook and probably Twitter these days. Well what if you don’t use Facebook can you remove the application? Nope you have to leave it there taking up space in your device. With a Nexus device you get only a small amount of Google applications and no additional third party applications. That way your phone can have more space for the applications you want to use. It really allows you to have more freedom with your device. Since you own the device you can do really what you want with it.

The third reason why I love the Nexus device lineup as their updates. You get updates right away when Google release them. With other devices you have to wait a lot longer period up to months. For example if you have an HTC phone or Samsung phone you have to wait for them to make their updates. After they make their updates they then send it to the carrier to apply their updates. From there it goes through a series of tests and if any defects are found the process starts again. So you could potentially end up waiting months for the latest updates instead of just getting them straight from Google. So the process can become very frustrating. Also there is the possibility that the carrier no longer apply’s updates to your device even if it has enough hardware for it. So basically you end up paying more for a device that is not flexible or getting updates.

If they chose to discontinue the Nexus lineup I hope they add another lineup similar. Which of course won’t happen for some time after. They wouldn’t discontinue just to add a similar lineup. I think users will be upset that they have to wait for the latest updates. I believe Google was on the right path with the Nexus lineup when it came to competing with other companies like Apple. Apple only manufactures their own devices which I think is a good practice but I believe the Google path of dual manufacturing was even better. This allows people to still have choices but at the same time they can get a pure Google device. I think with Android the more choices for manufacture’s the better. Google shouldn’t give less choices as it could upset their user base when they have no choice to get a pure Google device.

Android K-9 Mail

I have been using the K-9 mail application on Android for some time now. I have noticed that it has made some major improvements throughout the years. I would have to say that I am most impressed with their latest release. Their interface has always been subpar when you compared it to some applications on the market. For example the Google gmail application has always been really slick and interactive interface. Now with the latest release of K-9 which I downloaded yesterday on my phone seems to be catching up. They have updated their icons to be more modern. It also seems like they have spent a lot of time improving the interface and making it more usable. It’s always been a great application for managing multiple email providers and now it has a nice interface too.I would recommend this application to anyone who needs to manage multiple emails under one client.

Functional testing an Android application

I have been working with Android for years now. When I first started to work with it I never really thought about adding tests. As of late my application has gotten big enough to where tests are important. After doing some research I found that I was able to do both unit tests and functional tests. Unit tests are difficult in Android though because most of your code uses the Android helpers and you need to create mock objects. I decided instead of writing unit tests I would write some simple functional tests for the time being. To do that I used a tool called Robotium.

This tools goes along side of the Android functional test framework and makes things very simple. For example you can do this using Robotium.


solo.clickOnText("Add");

Instead of


clicker.clickOnText(text,false,1,true,0);

From my experience with it it’s been a great wrapper. It has saved me hours of writing my own wrappers for my tests. Also the time it took to create these functional tests did not take long either. I encourage anybody who has an Android application to use this wrapper to get their functional tests up and running.