FOSS4G was awesome!

Well, that was fun!

Some highlights of FOSS4G, in no specific order. There'll be some things to re-evaluate, some to prioritize and try to integrate into the next year at work, some side projects after hours, ...

FOSS4G was close by! It's only in the USA every third year, and last time (2011) it was in Denver. But this time, it was conveniently located only 2 hours away. Too far to go home every night, but close enough to stay with a friend and not need a plane ticket.

Meeting up with colleagues is one of my favorite parts. Before I get caught up in the deluge of data and techniques, I should thank again the folks I met at the conference: old colleagues like Karsten and Stephen and Matt and Bob, and new colleagues such as Tanner and Jim. It's been a pleasure meeting you; please follow my profile links and get in touch.

My presentation on the RCS Viewer was something of a dud. It seems that the 10am timeslot the morning after the party, on the last day (short day) just gets poor attendance. That's too bad: the RCS Viewer combines some of the best features for advanced GIS analysis with a simple "GIS whiteboard" as well as PDF take-aways. If you're interested, click here to see the slideshow and be sure to read the notes on each slide for some additional annotations describing the spoken part.

On the other hand, my presentation on MobileMapStarter was a real hit. I felt like a nervous, babbling idiot up there, but feedback afterward said something very different. Several folks came up afterward with compliments, good questions, intentions to use MobileMapStarter, ... and questions about licensing, because they want a clearly-stated license so they can get started using it. Huzzah! Don't worry folks, an explicit license is coming right up this weekend. If you're interested, check out the slideshow and again be sure to read the notes on each slide for the spoken material and other side notes. (oh, Chapter 1 and 2, on setting up the Cordova build environment are back up; see July 5 or so!)

MapServer 7 sounds like a small update, though in fact it seems to have involved a 25% rewrite of MapServer. Why do we use MapServer? It's lightweight and fast, configuration is dead simple (sorry, I do not consider it a painful chore to write mapfiles), you can dump temporary mapfiles to disk and use them for a session, it does variable interpolation, ... MapServer 7 brings performance improvements, then the ProTips had some useful tips, some of which I didn't already know. And lastly, MapCache is yet another tile caching system but one perhaps more flexible than TileCache and TileStache (it can handle raw WMS requests that do not fit tile boxes).

CartoDB's presentation on performance and caching was moderately enlightening. Perhaps the biggest take-home here, was the nature of their caching: it's not a tile cache holding a zillion PNGs, as much as a Varnish cache for the vector tiles that are to be rendered. Making a DB update hits a trigger that issues a varnishctl command. In conversation that day I had guessed about 2/3 of this just mentating on how I would do it... good to know that I was on the same brainwave as the smart guys. :) But it gets me thinking about whether Varnish or even CloudFront could do us some good over at GreenInfo Network, for general caching of not only map tiles but static assets such as PNGs and CSS files. (you know, network contention when downloading the 30+ assets which form a page)

RasterIO (not Raster I/O, but Rrrrrrrrasterio!) is yet another Python-NumPy-GDAL wrapper. But, it's a step beyond all the prior ones such as agoodle and even rasterstats. a) It wraps both GDAL and OGR, so you can handle both shapefiles and GeoTIFFs (et cetera). b) It uses a "more Pythonic" programming interface, e.g. using .read() and .write() c) It may consume far less memory than agoodle by virtue of being able to do a read() on a specific window of the raster, rather than loading the whole thing into memory. For one specific application where we use agoodle, this could be a game-changer.

Then some breathtaking demos of 3D data, such as Cesium. Mostly it was sit-and-spin sort of deals: load 3D data (NED), render a mesh, drape the photo (NAIP) as a texture, and there's a spinny 3D mountain demo, super cool. This is the part I find most visually intriguing, though at the same time the most baffling as to what anybody would do with it, at least as far as my customers who find a "find nearest park" application to suit their needs. I would love to find a use case for some awesome 3D stuff.

And Galileo seems like a very practical phone app that I'll probably download later this weekend. It loads OSM extracts (e.g. states in the USA) and provides a slick little pan-zoom UI. Imagine Google's "Maps" app or Apple Maps, but... without Google and Apple. If I heard correctly, it's for iOS only, which would be too bad since I'm an Android man. But I'll get on the newsletter and keep listening.

Google Closure Compiler keeps coming up. We're already in the practice of minifying our JavaScript code, but Closure goes an extra step and optimizes the code for run time performance. I've gotta give a look to this, see what differences we can achieve in file size and also runtime, compared to our existing applications.

Whew! The above are just the highest highlights that I'll be investigating at work, not even the really experimental stuff for when I get a slow day. WHAT A WHIRLWIND!

THANK YOU SO MUCH, FOSS4G!

FOSS4G here I come!

FOSS4G is in Portland, Oregon this year, a mere 2 hours away from my home. Huzzah!

I'm giving two talks:

• Wednesday afternoon (tomorrow!) I'm showing off MobileMapStarter. This is a starting template in HTML5, for a mobile app for use in Cordova/Phonegap. Copy, paste, and have a mobile app running in literally 10 minutes (5 if you use Phonegap Build).
• Friday morning, Tommy Albo will help me present the Intertwine's Regional Conservation Strategy viewer. This excellent web app, lets someone draw or upload an area and get back statistics about habitat valuation, park land, etc. The idea is that city planners and land developers can become aware that the area they're about to raze is actually valuable, and find an alternate location.

Beyond that, I'll be meeting friends, coworkers, and colleagues! Stephen from Cleveland. Karsten from Seattle. Keith from here in Corvallis. Tom from San Francisco.  I'm sure most attendees will agree, that hobnobbing with map nerds, is at least as great as the organized talks and events. :)

Mobile Development with Cordova (Phonegap): Afterword

I'd like to again thank GreenInfo Network, my generous employers, for giving me the time to learn, then giving me the okay to share the knowledge. Those 13 chapters are a distillation of real-world pitfalls and techniques, beyond the copy-and-paste world of books. I hope it helps. :)

Mobile Development with Cordova (Phonegap): Appendix C

Appendix C: Phonegap Build

Phonegap was originally an Adobe project -- and still is, Cordova is the open source version. Phonegap Build is a service provided by Adobe, to simplify the process of compiling your apps.

 

Simply put, you upload a ZIP file containing your www content (HTML, JS, CSS files, jQuery, et al) and simply upload it to the PGB website. They will then build the app for iOS, Android, and other platforms. This takes a lot of the overhead out of development, since you don't need a Mac, Xcode, Apache ant, a local copy of Cordova, etc.

But it's not a panacea:

• You do still need a Mac in order to use the Keychain Access program, to generate certificates and to convert certificates into the P12 format required by Phonegap Build.
• There is a limit of 10 MB of content in the ZIP file. This is quite generous for some apps, but our apps tend to include JSON and GeoJSON databases, pushing them over the limit or not leaving comfortable space for growth. There are techniques for downloading the database file over the network and storing on disk, so it doesn't need to be bundled with the ZIP file. But those are more complicated, and not as "zero maintenance" as simply bundling data that won't change except between versions.
• The cycle of waiting tends to be several minutes. Using local builds on the Mac, I can have turnarounds in 60 seconds on the iPad. On Android, I need to transfer and download the APK, which is ultimately about as time-consuming as the Build service.
• Android apps built in the PhoneGap Build, will not run in singleTop mode. This means that any time someone leaves the app, then resumes it by tapping the icon, it starts all over again starting with the splash screen and then the welcome page. This has been a reported bug for two years...

Because of these limitations, we don't use it anymore. But it certainly bears mention in any publication on the topic of PhoneGap and Cordova.

Mobile Development with Cordova (Phonegap): Appendix B

Appendix B: Generating a Provisioning Profile (iOS)

Your Apple developer career is managed by the Provisioning Portal. As described earlier, your key components are:

• A developer certificate
• An app ID, which is simply a logical grouping of applications
• A list of devices for beta testing
• A provisioning profile linking all of these together

Getting started:

• Log in to the Provisioning Portal
  https://developer.apple.com/
• Go into Certificates, Identifiers & Profiles
  If you don't already have a Certificate, generate one and load it onto your Mac.
  Make it a Production certificate, for "App Store and Ad Hoc"
• Defined an App ID.
  The simplest choice here is to make a wildcard matching your organization, e.g. org.greeninfo.* Using a wildcard will allow this provisioning profile to match multiple apps, as long as they start with org.greeninfo
• Enter the UDIDs for your beta tester devices
  Again, only devices listed here AND chosen for a Provisioning Profile can effectively beta test.
• Generate a Provisioning Profile
  Tie together your developer identity, your app, and those devices, into a single logical grouping.

When you're setting up your mobile app, you'll define a Team in Xcode, and Xcode will download your certificate and Provisioning Profile for you. You will find yourself doing this relatively often as project momentum builds and beta testers want to come on board. You will need to regenerate a provisioning profile and downloaded into Xcode every time. See the chapter about beta testers for more info.

Do not forget the 100 device limit. If you're doing apps for 5 or 6 companies, and each one wants 20 people to check out the app, you could run out of slots.

 

 

Mobile Development with Cordova (Phonegap): Appendix A

Appendix A: Generating a Certificate Keystore (Android)

Android apps must have a digital signature. For Android, you generate your own certificate, which is saved inside a "keystore" file. You generate this with the keytool command-line tool, which is part of the Android SDK you downloaded while setting up your build environment.

Generating a Keystore

The command below generates an Android keystore named android_certificate.keystore containing a single certificate named android, good for about 25 years (10,000 days), and with a nice large key size (8kB is current standard).
keytool -genkey -v -keyalg RSA -keysize 8192 -validity 10000 -keystore android_certificate.keystore -alias android

You will be prompted to enter a password, then for your "first and last name" which really means any identifier such as your company or department name, then other identifying info such as your location. Lastly you'll be asked for a second password to lock the keystore (as contrasted to the certificate itself) but I like to just use the same password for both.

In the end you'll have a keystore file. Back it up into a safe place along with the alias and password.

Warning: The certificate and keystore must be the same as you sign of future versions of the same app. If you lose the key store or forget the alias or the password, you will not be able to sign future versions of the app. The result is that anybody trying to upgrade, will fail: they will need to uninstall the previous version of the app before installing the upgrade.
 

Using the keystore in Cordova CLI Tools

An app compiled with cordova build android --release will not be properly signed and able to install onto phones, unless you instruct ant to use the keystore.

You can specify the path to the keystore file, as well as the alias, in the ant.properties file. This is described in the  Setting Up Certificates part of chapter 3 when setting up a new project.

Tip: I always use cordova build android --release so it prompts for a real certificate. This adds an extra step to the build/test cycle, but does ensure that the selfsame APK can be distributed to others (it's easy to forget, and send an APK that's not signed). It also ensures that I in fact have the keystore handy, as I am unlikely to lose it and then lose my backups over time, if I'm actively using it every day of development.

Mobile Development with Cordova (Phonegap): Chapter 10

Chapter 10: Distributing the App to Stores

Once you've created your mobile app and tested it thoroughly, it's time to distribute it!
There are multiple avenues for distribution: the Apple App Store for iOS, and two major app stores for Android.

Android: Google Play

This is arguably the most popular of the app stores for Android.
Sign-up is based on the same Google account that you probably already use for Gmail or Google Docs.

https://play.google.com/apps/publish/signup/

On the Dashboard, use the "Publish an Android App on Google Play"

There are rather a lot of questions if you're establishing a new app, though many can be skipped if you're simply updating a new APK. The most time-consuming part is making up the rather large set of icons and screenshots. It took me about 45 minutes my first time.

Android: Amazon App Store

This is arguably the second most popular of the app stores for Android.
Sign-up is based on the same account that you already use for shopping at Amazon.com.

https://developer.amazon.com/public/

On the Dashboard, use the "Add a New App" wizard.

There are rather a lot of questions if you're establishing a new app, though many can be skipped if you're simply updating a new APK. The most time-consuming part is making up the rather large set of icons and screenshots. It took me about 45 minutes my first time.

iOS: Apple App Store

As in most of the steps previous, submitting to Apple's App Store is more complicated than for the Android stores, but then again also more polished in some ways.

As a quick overview, there are three steps to submitting an app to the store, once you're done testing it extensively.

• Create an App Record in iTunes Connect (the web portal for managing App Store apps). This is only necessary if you're submitting a new app, not for upgrading an existing app.
• Build an Archive of it (the IPA file) and sign it with a distribution Provisioning Profile intended for Store Distribution. In that same Archive operation, proceed to upload it to the App Store.
• Wait for approval, or for an explanation of why the app was rejected.

Creating the App Record

Creating an App Record is just what it sounds like: creating the app's description, screenshots, etc.  Naturally, you only do this for a new app and not for every upgrade of the app.

This is done via the iTunes Connect website https://itunesconnect.apple.com/
Follow the Manage Your Apps option, and the Add New App button.
It's a tedious process like all the app stores, especially the need for various screenshots and splash screens.

Tip: Apple requires screenshots from a variety of devices, including an iPad, a 3.5" phone, and a 4" phone. As such, you and your beta testing team will need at least one of each of these devices. Apple is very clear that you cannot simply resize an existing image, and I have a feeling that they really are paying attention.



At this point, if you visit your app dashboard on iTunes Connect, you should see that it is waiting for upload.

Building and Uploading the Archive

Open up the Xcode project file, and make sure you have a physical device attached. The archive option will not be available, unless you have a physical device attached.

Go into Project/Archive, and follow the wizard same as you had when you are making Ad Hoc builds for your beta testers. But this time, select a Provisioning Profile intended for store distribution. Then simply walk through the wizard.

At this point, if you visit your app dashboard on iTunes Connect, you should see that it is waiting for approval.


Tip: You app record must be Waiting For Upload. If you already uploaded, but want to make a change, you must cancel your previous upload via the iTunes Connect website, which puts the app back into a Waiting For Upload state.



Approval

Apple is proud of their stringent testing process. I wasn't happy about it first, but I must admit that it's a good thing. They test on a variety of devices, and they make sure that your app isn't consuming the users' valuable iCloud space.

But keep at it, follow their instructions, and eventually you'll get through.