This concerns The Library Herald app.
I want to record and share a few of my observations about making and distributing my first Android App. As background, I have built websites since 1993, and while that does not make me an expert, I still have a certain amount of experience working with web technologies.
After that page, I made another site, based loosely on this one, so that I could get some idea of how WordPress functions, and I created the Library Herald (link). This was even simpler, since almost all it needed was to copy and paste into a WordPress plugin.
First, I needed to figure out what kind of app to build. There are web apps, native apps, and hybrid apps. A web app would have been pretty much what I mentioned above: to create a website to be accessed by a browser, but designed specifically for certain screen sizes or even certain devices. I found out that some very big organizations have done this, no less than The Wall Street Journal and the New york Times (links). I decided I wanted to try something different.
A native app is specifically written for certain devices. Therefore, Apple native apps run only on Apple devices; Android native apps run only on Android devices; Windows native apps run only on Windows devices, and so on. The advantage of these apps is that you have access to the mobile device’s full capabilities; therefore, native apps are normally faster and have more functions than other apps.
Hybrid apps are just like they sound: they do some of both. Each has their strengths and weaknesses, and for those who are interested, a good overview is available at http://www.nngroup.com/articles/mobile-native-apps/
None of this really surprised me but I was struck by another difference: a difference in philosophy. Whenever I had built something for the web, I did not design for specific browsers—although I would check how something displayed in different browsers, I expected that each browser to work pretty much the same, no matter if it is Firefox, Explorer, Chrome, Opera, Safari, or any other. In other words, I assume that everyone should be able to use and read the files I write, because the browsers are designed to work more or less in the same way.
Sometimes you do have to write something special for a specific browser, but I have considered the need to do that similar to dealing with a bug—or at least that’s how I considered it. You don’t have to do this nearly as often as before, however. These special scripts were almost always directed at Internet Explorer (or IE). Note
IE never worked as well as the others, but since so many people had Explorer (because it was the default browser in Windows) you couldn’t ignore it and had to deal with it. If it was a problem with a lesser known browser, you could be less concerned. The assumption has always been that the browsers should be made to handle what you give to it, otherwise it’s a bug.
With app development however, this attitude changes, especially with native app development. With Apple iOS development, you are creating specifically for Apple products; with Android, just for Android products, and so on. As a consequence, those companies don’t have to make you happy—you have to make them happy. While I had been aware of this before, it wasn’t until I sat down and starting considering how to make an app that it struck me how limiting this is compared to the web. If you make a native Apple app, then you have to completely recreate the app for Android or you wind up losing a huge number of people, and again for Windows, and Blackberry and so on. That is an immense amount of work. Too much for me.
It seems to me that if web development since the 1990s, had been the same as app development, the web would not be considered as free as it has become–for better or worse. Personally, I like the freedom.
With HTML5, you can also store data on the mobile device, or in the web browser. Before HTML5 you could only store a small amount of data on a client’s machine, pretty much limited to the cookies, which have a maximum of 4 KB, or maybe 2 pages of text, maximum. With HTML5, you can have entire databases on a local device.
You can even make ebooks with HTML5. I’ve already made a couple with epub but it would seem HTML5 allows some other possibilities. Imagine: a book (or ebook—I see little difference in the two now) with all the capabilities of a website. And not just any website, but an advanced website. That is impressive.
One of the greatest advantages of HTML5 that interests me is that it can make apps that work on all devices. This is probably what I will choose to do, but maybe I’ll just go for a web app. I would be in good company.
HTML5 is considered by many to be inferior to native apps, which is probably true since native apps will always be able to access more functions on a device, and do so much more efficiently. Nevertheless, I think that HTML5 will be able to do anything I would want. The process of making an HTML5 app is still a little clunky but doable. To oversimplify, the process is to create the resource in HTML5, and other web technologies, and then you port it out into the different operating systems: Android, Apple, Windows or whatever. The major tool to do this is Eclipse. I’ve made some very rudimentary apps this way but I want to do more.
The other big change that I noticed with developing apps vs. the web was when I rolled it out. On the web, you put up a site, let as many people know about it as you can, today using the social sites such as Facebook and Twitter, wait until Google and Yahoo and the other search engines index it, do any kind of SEO you want, and that’s it. Apps are different.
While I could have done the same thing—just put the Android app file (called an APK file) on my website and announced it, it seems that you really have to be in the Google Play store today, or the Apple app store for Apple apps. Otherwise, you are nowhere. Although you can load an app file that is not from the Play store onto your phone by sideloading it, you still need to know that you can download it onto your mobile device, find the file, click on it, then CLICK OFF the option that you want to load only apps from the Play Store, and then install as normal.
This is an example of some other of the subtle effects defaults can have. Google sets the default not to allow you to install any app you want but only those on Google Play (where they get money). The install could be to allow you to install anything you want, and you get a warning about unapproved apps. In this way, Google tries to ensure that people will want and use only those apps that are in the Play Store, which they control.
Still, I thought: OK, let’s sign up. It cost me a little money. And when I did, I found what seemed to be a really nice area for Beta testing. I thought that I could bring out a Beta test first and then put out the full version only later after some tests. On the web, if you want to make a Beta version, you simply put it on the web as you always do, and make a link to it saying, “This is a Beta version, so be careful and let us know how it works,” that is, you make a Beta version just as you do anything else. You just call it “Beta.”
In Google Play however, to make a Beta version of an app, you need to make a Google Group or a Google+ Community, and then anyone who wants the Beta version must first join the Google Group or Community—and to do that, you must first get a Google account! Google has quite a bit of control over the entire situation.
Anyway, I didn’t understand the ramifications of making a Beta version and the entire roll out became somewhat of a drama very quickly. It turned out that people could not get to the app, so I decided to get around it by just turning it into a full version. I learned that doing Beta testing for apps is much different than for web pages.
At least it wasn’t as bad as the rollout of the Obamacare website!