Android Development Setup Woes

I had been testing my Ionic app on an iPhone for a while when I thought I should try it on Android, after all that is one of the main selling points of hybrid mobile app development. Setting up the development environment for iOS on Mac OSX was super simple, until the convoluted certificate, key & provisioning chores. Super simple in comparison to Android development setup at least.

First of all I had to install the Android SDK, which, of course, is fair enough. Then I had to set up a virtual device, which again is fair enough. I started the simulator, oops I meant emulator… and several minutes later… nothing. A bit of Googling led me to install all the Tools and Extras for the latest Android SDK.  Now I’m getting somewhere, very slowly, …. at least Ionic claims that that the app has been installed and launched! Well, no it hasn’t actually…”Launcher 3 has failed”! FFS! What’s up now?

It turns out I’m not the only one to have issues with the Android emulator on Mac OSX. I turn to Genymotion. I download and install Genymotion. That doesn’t work either! FFS! It turns out I need to install VirtualBox first. FFS! No, in fact first I have to “Allow apps downloaded from: Anywhere” in Mac OSX to run Genymotion! FFS!!!

Finally, I get my Ionic app running on a Galaxy S6 emulator, and to be fair to Genymotion it is pretty quick compared to the standard emulator. Happy days… eventually. Then I remember that I haven’t got as far as creating the Android equivalent of Apple’s certificates, etc…

Advertisement

Is AppGyver the Best of Both Worlds for Mobile App Development?

AppGyver claims that it is the “Best of Both Worlds” when it comes to mobile app development, enabling non-coders and coders alike to build and distribute apps easily and quickly.

I was hired by a client to recommend a mobile app development platform for use by people with ideas but no coding experience. A simple app builder not just for the front end but also the back end was required. I evaluated several tools from a competitive and fast moving market. AppGyver stood out as the platform that wasn’t limited by its drag and drop simplicity. In addition to a drag and drop app builder AppGyver can be extended with custom built modules allowing non-coding and coding approaches to be combined.

Composer is AppGyver’s visual app builder; part interface builder, part data source integrator and part build service. Composer is a simple and intuitive tool allowing non-coders to develop and deploy a simple data driven app to a smartphone in minutes. AppGyver uses QR codes and its own scanner app to provide the easiest and quickest method of distributing apps for review that I have come across.

Steroids is AppGyver’s command line interface for building and distributing apps. It provides a useful connect screen that allows the app under development to be connected to the AppGyver and other cloud services. A word of caution… to avoid cryptic errors use nvm 0.30.x, node v0.12.x and npm 2.14.x when using Steroids. At the time of writing npm 3.x was causing undesirable side effects when on Steroids .

Supersonic is AppGyver’s framework, a fork of the open source Ionic Framework. It adds a little bit of AppGyver magic to the mix that gives near native performance by using native UI components to give quick and smooth page transitions. Accessing data is simple through the framework, e.g. supersonic.data.model(‘Beer’) gets all the beers from a configured data source.

Composer pricing will be an issue for many. I’d recommend checking it out before getting too excited, although AppGyver do appear to be flexible and open minded about pricing options. Steroids and Supersonic are free to use.

I hope this helps someone who is looking for a non-coder friendly way of developing mobile apps that also appeals to coders. It won’t be for everyone but it should do well in what I guess is a niche market.

I’ve attached a presentation that I gave recently at a smart data hack, where I was trying to convince people to try AppGyver out. Unfortunately no one did try AppGyver but that was probably down to the time constraints of the hackathon. However, it was still a bit of a pity as I think this tool really has potential.

Retired Trialist

I thought it would be worthwhile documenting the proof of concept app that I developed last year.

This was built with the Reboot Landing Bootstrap theme. There are issues, front and back, so I’ve decided to “freshen” several areas but there are some features worth keeping, e.g. texting players directly from the app on an iPad.  You can find the code here. And this is what it looks like, the retro style font used in the playermanager logo is YWFT Trisect

playermanager-trialist

Trial Match

“Blue and green should never be seen, except on the head of an Irish queen” I remember my mother saying to me when giving me some fashion tips, probably about my blue and green tank top. I my defence it was probably in the 70s. Personally I like the combination of blue and green and think it makes a nice colour scheme for a footie app; Rangers and Celtic, blue sky and green grass, blue sky thinking (really?) managers and players …erm, coz they play on grass.

Blue and Green Theme

I googled for some example and came across this post at Crazy Egg, number 7 Lake Nona with its “fresh, modern color palette” looked good to me. Next up was choosing a Twitter Bootstrap theme. Cerulean from Bootswatch was a possibility, but I ended up splashing out $4 on Ericka and a ridiculous $15 on Reboot Landing from WrapBootstrap. Combining elements from all of these themes was beginning to feel like it might just work. But I needed some nice icons…

Font Awesome

The icons from Font Awesome are actually awesome. Designed to work with Bootstrap they are unbelievably good looking and easy to use and all for free. I plan to use them liberally throughout. So far they are on the index page, coloured to match the theme. The masthead icon and favicon have also been created from the font as well, pasting the font into Adobe Illustrator and exporting as a PNG.

Google Fonts

Google’s Oswald font is used both in PlayerManager and in the theme for this blog. It somehow reminds me of football shirt fonts.

Result

The most important thing is the result…

playermanager

And on the touchline…

Mini-iPad-B&W-Mockup

Thanks to Pixeden for the iPad mockup. You can get the source code here.

PlayerManager – Qualifying Round (Application Server)

Tomcat, TomEE or GlassFish? I like the simple life. But getting to the simple always seems to take so long. And with enterprise java sometimes even longer than that… I was experimenting with Java EE 6 RESTful Web Services and Entity beans generated with NetBeans when I thought it would be good to test how easy it would be run this app on Tomcat, TomEE and GlassFish. Well, with Tomcat I would have to build my own Tomcat based Java EE 6 server (again). To be honest I couldn’t be bothered and the guys at TomEE had already done that. So it was between GlassFish, the reference EE server, and TomEE.

Running one of the sample NetBean apps, Customer Database on Spring, on GlassFish is as easy as you might expect, but porting that to TomEE was more difficult than I expected… With TomEE there is a choice to be made from the 3 versions currently available; standard, web services and enterprise options (not the official names). I really only wanted the web service version (Java EE 6 Certified JAX-RS) for its RESTful web services but as I wasn’t sure if that contained everything that I would need I went with the enterprise version (TomEE 1.5.1 Plus) which has the most supported APIs.

With the TomEE version choice made I started googling for what seemed like days for documentation, help, examples, anything that would help me to configure  an app on TomEE, an app that took minutes to write in NetBeans and run on GlassFish. Finally stumbling across this I was able to piece together what was required to get things working on TomEE.

A resources.xml file needs to be in the WEB-INF/classes/META-INF folder to define a data source, e.g. this example defines a Derby data source.

<!--
A TomEE 1.5 Resource definition file used to configure application specific resources.
Location: <webapp>/WEB-INF/classes/META-INF/resources.xml
-->
<resources>
<Resource id="jdbc/sample" type="DataSource">
JdbcDriver org.apache.derby.jdbc.ClientDriver
JdbcUrl jdbc:derby://localhost:1527/sample
UserName app
Password app
JtaManaged true
</Resource>
</resources>
view raw resources.xml hosted with ❤ by GitHub

I also had to update the persistence.xml file to use the EclipseLink JPA provider as I just couldn’t get the default TomEE JPA provider (OpenJPA) to work…

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0"
xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
<persistence-unit name="CustomerDBSpringPU" transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>jdbc/sample</jta-data-source>
<class>customerdb.Customer</class>
<class>customerdb.DiscountCode</class>
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<properties/>
</persistence-unit>
</persistence>
view raw persistence.xml hosted with ❤ by GitHub

TomEE 1.5.1 doesn’t like Spring injecting an EntityManager, as documented here. So I removed that from the Spring config, instead relying on the GlassFish managed entity manager. No big deal there, and not a big deal either to remove the lines of code that were closing the entity manager, as that isn’t allowed with a container manager entity manager.

All in all it wasn’t too hard to prove that a simple Java EE 6 app can be ported from GlassFish to TomEE.

Mac Mini 2007 with OS X Server

Man alive! Against all expectations I’ve managed to upgrade my 6 year old Mac Mini (mid 2007 aka Macmini 2,1) to Mac OS X 10.7.5 Lion Server.

Memory
Upgraded memory from 1GB to 4GB as the minimum for Lion is 2GB. Apparently the max for my Mac Mini is 2GB or 3GB depending on what out-of-date website you believe.

Lion Server
Signed up to Mac Developer Program for £60 to get access to downloads of Mac OS X, Server add on, etc. My Mac Mini’s architecture doesn’t support Mac OS X 10.8 Mountain Lion. Although Lion is available from Apple (for about £20 I think) but not via the online store. Upgraded from Mac OS X 10.6.8 Snow Leopard  to 10.7.5 Lion with the Server add on.

Fan
Waited for Spotlight to stop indexing. Wondered why the fan on the Mac Mini was going mental even after Spotlight had finished doing its stuff. Realised that I hadn’t reconnected the fan after the memory upgrade. Attached the fan cable.

Server vs iCloud
Decided not to bother using the Server functionality to share calendars, contacts, etc but to go for the convenience of iCloud instead.

And finally … bish, bash, bosh I have a Mac OS X Server ready for testing and other stuff like iTunes streaming via TwonkyServer which works well on DLNA devices.

In the end it wasn’t too painful and I feel as though I’ve saved myself about £800 on the cost of a new Mac Mini with OS X Server.

Development Environment II

I’ve been rethinking using Eclipse as my Java & HTML5/JavaScript IDE of choice since discovering that NetBeans 7.3 supports both, and with integrated Chrome JavaScript debugging and Twitter Bootstrap, BackBone.js and Jersey RESTful WebServices support it seems too good to be true. But after getting a couple of building a couple of simple apps with NetBeans it could be time to wave goodbye to Eclipse plugin hell and say hello to NetBeans simplicity.

One thing I couldn’t figure out was why the CustomerDBSpring sample app and the CustomerRestfulService  app were producing different JSON. It turns out it was all down to how Jersey was configured to convert Java to JSON. This guy describes the problem well and the first solution that I tried, but clearly that wasn’t a great long term option. The longer term solution was to use Jersey’s POJO support, which basically amounts to sticking this in your web.xml.

<init-param>
  <param-name>com.sun.jersey.api.json.POJOMappingFeature</param-name>
  <param-value>true</param-value>
</init-param>

BTW I don’t usually blog on a Saturday night, not that I’m saying there is anything wrong with that, but its just that my wife is watching the final of Strictly Come Dancing 😦

Development Environment

The development environment is based on Mac OS XEclipse 4.2 (Juno) for Java development and Google Chrome with the JSONView plugin for JavaScript debugging.

One of the challenges was to replicate the technical architecture of the production environment in the development environment. Installing Apache HTTP Server, Apache Tomcat and MySQL was a skoosh but mod_jk on OS X was a different issue. In fact I had problems with the subversion plugin for Eclipse 4.2 and upgrading from Eclipse 3.6 to 4.2.

mod_jk
No easy download and install for mod_jk on Mac OS X, oh no you have to get the source code and build it your self. After downloading the mod_jk source …

cd tomcat-connectors-1.2.37-src
./configure --with-apxs=/usr/sbin/apxs
cd native/
./configure --with-apxs=/usr/sbin/apxs
CFLAGS='-arch i386 -arch x86_64' APXSLDFLAGS=' -arch i386 -arch x86_64' ./configure --with-apxs=/usr/sbin/apxs
sudo make install

And bish, bash, bosh I had a /usr/libexec/apache2/mod_jk.so

Eclipse 3.6 to 4.2 upgrade
Upgrading from Eclipse 3.6 to 4.2 didn’t work, but I put that down to the Flex plug-in. I gave up on that upgrade and installed a new 4.2 version and backed out the upgrade on 3.6 with the wonders of Time Machine. I need the 3.6 version to support the Flex apps I’ve built with Eclipse 3.6. I have an elephants graveyard eclipse versions on my machine.

Unfortunately the 4.2 Juno release initially ran like a dog. It would take several seconds to just open a file, I’m not the only one to experience this problem. Increasing the memory allocation in the eclipse.ini file soon sorted this problem though…

-Xms1024m
-Xmx2048m
-Xss2m

Subversion plugin
Using the subversion plugin from  Eclipse 4.2 on Mac OS X also needed a bit of work, this time having to install subversion and a load of other Darwin port stuff. The magic that worked for me was…

sudo port install subversion-javahlbindings +no_bdb +universal
sudo port -f activate subversion-javahlbindings

Technical Architecture

I’ve decided to build the playermanager app with a classic 3-tier architecture;

  • HTML5 presentation tier
  • Java RESTful web services middle tier
  • MySQL database data tier

HTML5 presentation tier
Choosing HTML5 and JavaScript for the front end was a difficult decision. After putting a fair bit of effort into Flex in the last five years it felt bad ditching ActionScript in favour of  its ugly sisters HTML and JavaScript but with the likes of Twitter Bootstrap and Backbone.js things have changed a lot since I last fiddled with them. There seems little no point in dusting off my ancient copies of HTML: The Definitive Guide  and JavaScript: The Definitive Guide, or even giving them to the  Scouts Fall Fair, I’ll just need to splash out on new ones.

This tier will be served alongside other static web content from the playermanager.net website on an Apache HTTP Server, passing any Java RESTful API calls to the Java tier below via mod_jk.

Java RESTful web services middle tier
A RESTful web services tier seems like a good a choice from a Service Oriented Architecture view, developing services so that different clients, e.g. mobile apps, browsers, FIFA, can make use of playermanager services via a RESTful API.

Choosing Java for the implementation of the RESTful API was a fairly easy decision. In my experience RESTful Java web services written in Jersey producing and consuming JSON are a very lightweight and productive option. Using Spring in the Java tier seemed like a good choice based on industry best practice and extensive Jobserve research; Spring Security to secure the RESTful API, Spring’s data access framework with Hibernate to simplify the reading and writing of data in addition to Spring’s dependency injection are all tried and trusted methods.

The Apache HTTP Server of the tier above passes on any Java RESTful web services API calls to an Apache Tomcat Java Server that services any URL beginning /api.

MySQL database data tier
MySQL was an obvious as its simple and open source with good developer and admin tools.

Currently all of the tiers above run on one CentOS machine, hosted by enciva for £10 per month, but there is scope for scaling this architecture when playermanager goes global. And will scale further with the addition of caching where appropriate, e.g. mod_cache and Ehcache.

So that’s the architecture in a nutshell. Next up is the development environment.

Jogo Bonito

I’ve been looking around for a nice WordPress theme. Christophe Coenraets does a fine blog with StudioPress Minimum theme but that is more the reassuringly expensive option. This Blaskan one seems like a good free choice, it’s responsive, clean and uncluttered. All I think I need to add is source code formatting and a GitHub respository to share example code.

class JogoBonitoApp {
    public static void main(String[] args) {
        System.out.println("The Beautiful Game!");
    }
}

And for Gists…


package net.playermanager.samples.HelloWorld;
public class HelloWorldFootballApp {
public static void main(String[] args) {
System.out.println("Hello World Football");
}
}