That Coding Guy

Tech Tips and Tales, and Lessons Learned

How to Create a Cross-Platform Utility Library for Xamarin

By

Creating shared utility libraries in a cross-platform Xamarin environment adds challenges when compared to creating standard single-platform libraries. This post shows the architecture I use to easily handle those challenges, with detailed steps and settings for creating the libraries and for their use.
 

Overview

Every development group has at least one “utility” library that holds the common code they use in most of their projects. That code could be anything from logging routines to string extensions to database or HTTP functions, and it might also include routines for graphics or screen drawing, user alerts, or other UI-centric code.
 
For groups doing cross-platform development in Xamarin/C#, creating libraries that work properly in a cross-platform environment adds extra complexities. Although the basic routines like string extensions or datetime functions are common across all platforms, anything relating to device hardware or user interface or even file I/O varies by platform. Even code that might normally be thought of as “common” may in reality vary by platform, including logging or certain datetime functions or even some string handling. This adds new challenges to the task of creating a simple, shared utility library. 
 
The typical approach for creating and using cross-platform code in a Xamarin environment is to use dependency injection or the ServiceLocator pattern, resolving references to the library classes at runtime. This works well for larger subsystems and more complex components, even for code that is inside the application itself, but it is overkill for accessing the multitude of smaller routines typically found in an external utility library. Also, using those strategies to access small utility classes leaves the calling code littered with excess “noise” for things as simple as converting a datetime value.
 

One Approach

One approach to solving this problem is to separate the utility code into two different sets of libraries: a common library that contains only the code that works across all platforms, then another set of platform specific libraries, with each platform-specific library containing the version of the code for that one platform. However, this approach pushes the burden of knowing whether each and every library routine is platform-agnostic or platform-specific onto each developer who wants to use them in order to know which libraries to reference in each class. Even worse, for utility classes where most of the code is cross-platform but where a few methods vary by platform, you need to create two different classes, one in each library, with class names that are similar-but-different: “DateTimeUtils” for the common methods vs. “DateTimeUtilsIOS” for the iOS-specific methods, for example. Although you could use the same class name in both libraries, doing so would require you to more fully-qualify the class name on each use, referencing something like “XPlatUtils.DateTimeUtils.DateTimeOffsetToUtc()” for a common method vs “IOSUtils.DateTimeUtils.DateTimeToNSDate()” for an iOS-specific method, for example. It’s ugly and it smells bad.
 

Parse.com is Dead; Long Live Parse Server

By

Parse.com announced on January 28th that they will be shutting down. Although this is disappointing news, the way Parse is handling the shutdown is exemplary. They are giving their customers one full year’s notice before they shut down their services, they have open-sourced their core technologies and all of their SDKs, provided a series of guides on how to move applications over to replacement service providers, and provided tools to assist in those migrations. In theory, it should be possible to move an app from Parse.com over to other providers with minimal downtime and minimal code changes. My testing so far has shown that theory to be correct.

I’ve completely moved only one of my systems so far, but the transition was indeed very straightforward and relatively simple. After spending some time to get familiar with the Parse server code, the actual time required to make the few changes necessary to my code was very small. My new Node.js server is based on the example parse-server-example GitHub code, but the server is just a very basic, standard Node.js server plus any Cloud Code and any static HTML files. All the Parse.com features are provided by the open source parse-server Node module.

The example server code required only some minor customization and configuration changes (and a small fix of a server bug) to be functional. My iOS and Android apps needed an update only for the new REST server URL, and my Parse Cloud Code needed only a few very minor security-related changes. My database needed no changes although I did have to create some maintenance and backup scripts for the new database host. Add in some testing time and that was all the effort it took.

The following are the service providers I chose. In each case, the vendor offers a free plan that provides decent capacity and also offers a series of reasonably-priced paid plans to scale up when the need arises. I already have other systems on these providers and I am happy with them.

  • Node.js Server host: Heroku.com, although I am still considering using MS Azure
  • MongoDB Database host: mLab.com – this is MongoLab.com with a new name
  • Email service: Mailgun.com – I am currently using this just to send registration confirmation and forgotten password emails
  • Notifications: N/A – I was just about to release an update to this app that included notifications when Parse announced their shut down so I decided to hold off on that for now. I may handle notifications myself, leveraging the open-sourced parse-server-push-adapter, or I might use one of the other available services. If I do move the system to MS Azure, Azure Notification Hubs is also a very good option.

There is one bright spot with these changes: because the Parse server is now open source, I can much more easily extend the services of the RESTful server and provide additional functionality when I need it. I still love the ease with which I create a system using the Parse platform — see this post for details — and I love all the features the Parse platform gives me out of the box and the ability to use Cloud Code for simple server-side code. However, one concern I always had with a Parse-based solution was that Parse’s Cloud Code could only go so far, so while it was fine for smaller or simpler systems, Parse never seemed like a good option for larger or more complex projects. With these changes, I now have full access to a real Node.js server while still being able to use the Parse “wrapper”, thus giving me the power to quickly start with a simple, “2-tier-like” system but easily grow into a more powerful system as necessary. If Cloud Code alone is not sufficient, I can now create standard RESTful services using normal Node.js code, and thus have infinite capability.

I’m still not thrilled with Parse.com shutting down — we are losing a nice, effortless, single-vendor solution and replacing it with the need to juggle multiple services and service providers — but perhaps the longer-term benefits outweigh the losses. Perhaps this is now the best of both worlds: we can start a system quickly and simply, but have no real limits on where and how far that system can grow.

Parse.com may be dead, but long live Parse Server!

Fixing Xamarin.iOS “Error: No installed provisioning profiles match the installed iOS signing identities”

By

So you just downloaded someone’s code sample from GitHub, loaded it into Xamarin Studio on your Mac, started to build the app for the iOS Simulator … and promptly got smacked by the big red error message saying “Error: No installed provisioning profiles match the installed iOS code signing keys”.  Fear not — the error message is wrong. You aren’t missing a provisioning profile. Provisioning profiles are only needed when building for an actual physical device — they aren’t needed for running iOS apps on the Simulator.

The fix is simple: most likely the project had been erroneously saved with a “Custom Entitlements” value for the iPhoneSimulator platform. (One of the older versions of Xamarin.VisualStudio used to do this.) Open up the “Build / iOS Bundle Signing” page for the iOS project settings and blank out any “Custom Entitlements” value for “Platform: iPhoneSimulator” — it probably contains the value “Entitlements.plist”. Rebuild the project; all should now be well.
 

Parse.com Cloud Code is like JavaScript Pseudo-Triggers on MongoDB

By

Using Parse.com allows me tremendous simplicity when writing mobile apps: it lets me focus on just writing the mobile code and the database, but lets me use an N-tier deployment model and a remote NoSQL database. However, there are times when I really want to run a tiny piece of code inside the database — the same way I would use stored procedures or triggers in a relational database — or inside the REST server as I would normally do with server-side business logic.

For example, one of my mobile apps (PatchTrader) enables Scouts to more easily trade patches at large Scouting events. In this app, whenever a Scout “checks-in” at a new location, any of their older check-ins should be marked as expired in the remote database. I could have the mobile app save the new check-in to the remote database, then retrieve any old check-ins for that user and reach back to the server to expire each one, but this is a terrible use of mobile bandwidth and battery life. It also very fragile. PatchTrader is used at campsites with bad cell service, so it is very possible that the app will be unable to successfully complete all that work, thus leaving old check-ins still showing as “active” in the database. In an ideal world, I’d want a database trigger to fire on the first update and mark the other rows as expired, or I’d have my “check-in” RESTful service handle this … but I didn’t build a REST server and I’m not on a relational database.

Enter Parse’s “cloud code” — it fills that need nicely, and once again saves me from having to write a full server application when I just need one little bit of server-side code.

Parse’s “cloud code” allows you to run custom JavaScript inside the Parse server rather than in your client app, but still without requiring you to build a real REST server. You can use that cloud code to do things such as providing custom server-side logic, doing more efficient database processing or specialized counts, sending push notifications, and most importantly in my “PatchTrader” case, it provides hooks for code that can be run before or after a database object is saved or deleted in the MongoDB database. Pseudo-triggers on MongoDB!

Admittedly these are not real triggers but instead merely server-side JavaScript that is called by Parse’s underlying Node.js engine, but they feel like database triggers so calling them triggers better fits my mental model. And while one could argue that database triggers are evil because they hide business logic inside the database rather than keeping it visible in the server-side code, my DBA hat would reply that there are valid cases for triggers. Then my developer hat would chime in and explain that in this case, PatchTrader is a free app with a very limited audience that I’m doing in my spare time and it is tracking nothing more serious than map check-ins while trading patches, and my time would be better spent enhancing the app rather than building a REST server for it, so the trade-off is acceptable.

To show a simple cloud code example, this is the “after save” code that gets fired off by the server whenever a new check-in is saved by a PatchTrader user:

Parse.Cloud.afterSave("Checkin", function(request) {

    // Skip the update if we are being updated by server-side code
    // (i.e.: if this afterSave call is being cascaded from a previous afterSave call)
    if (request.master) {
        console.log("Cascading afterSave ignored on ID: " + request.object.id);
        return;
    }

    // mark any other "active" checkins for this user as "inactive"
    query = new Parse.Query("Checkin")
        .equalTo("user", request.user)
        .notEqualTo("objectId", request.object.id)
        .notEqualTo("isActiveCheckin", false);
    query.find( {
        success: function(results) {
            console.log("Updating " + results.length + " items...");
            for (var i = 0; i < results.length; i++) {
                var checkin = results[i];
                console.log("   Updating ID: " + checkin.id);
                checkin.set("isActiveCheckin", false);
            }
            Parse.Object.saveAll(results, {useMasterKey: true});
        },
        error: function(error) {
            console.error("Error setting items to 'inactive'." +
                " Error: " + error.code + " : " + error.message);
        }
    });
});

 

As you can see, it’s very simple and it gets the job done without adding any extra burden to the mobile app or mobile bandwidth, and it prevents bad data from gathering in the database.

It’s very handy, when used appropriately. If you’re a Parse.com developer and you haven’t played with Cloud Code, I urge you to take a look!

How to Restore a Single iOS App from a Backup

By

As an iOS app developer, there are times when you need to restore an old version of an iOS app from a backup. Or perhaps the vendor of your favorite app released a particularly bad or buggy update, and you’d like to go back to the previous version until they fix their app.  This post gives the step-by-step instructions on how to restore the old app version.
 
Update: This technique only works up through iOS 8. As of iOS 9, iTunes no longer backs up the .IPA files to the local computer so for iOS 9 and later, this technique is no longer usable.
 
Preliminary Notes:
  • I am using iTunes 12.2 on Windows with iOS 8.4.1 for the directions below although this should work in iTunes on Mac OS X as well.
  • The directions assume you’ve made a backup onto your laptop or desktop computer. Backups to iCloud won’t work.
  • If successful, this will restore both the old version of the app plus any data that had been backed up for that app.
 
Steps to Restore an Old iOS App Version:
 
  1. In iTunes, TURN OFF automatic syncing of devices.
    • In Windows, this is in “Edit -> Preferences -> Devices”
    • On Macintosh, this is in “iTunes -> Preferences -> Devices”
  2. Do NOT update your apps in iTunes.
  3. On the iPhone, delete the existing app from the phone.
    • If you don’t delete the existing app from your phone before doing the backup below, the backup will overwrite the old app version in your backup with the new version from the phone.
    • If you do accidentally do this, see “How to Import an Older App Version”  below for how to fix this.
  4. Connect your phone to your computer. Wait for it to appear in iTunes.
  5. Select your phone in the iTunes left panel under “Devices” or via the “Device” toolbar button.
  6. Back up the existing apps from your phone to your computer via “Transfer Purchases” in iTunes.
    • This is done either by right-clicking on the “Devices -> Apps” menu for your phone or selecting “File -> Devices -> Transfer purchases from [your phone name]“.
    • On Windows, you may need to press F10 to see the File menu.
  7. In iTunes, click the “Apps” button at the top of the Summary page for your phone.
  8. Scroll down through the list of your apps until you find the app you want to restore. The button next to the app should read “Install”.  Click this button.
  9. Click the “Apply” button down towards the bottom right of the iTunes window.  This will start the normal syncing process, and it will also reinstall the app onto your phone.
    • The status bar at the bottom of the iTunes window might make it look like all your apps will be removed. Don’t panic — they won’t be.
  10. The replacement app — the old version that you just restored — will appear in the first available icon position on the iPhone. If you previously had the app in a folder, you will need to manually put it back into the folder.
  11. If everything worked, cheer wildly.
 
How To Import an Older App Version into iTunes:
 
If you did accidentally overwrite the old app version in your backup with the new version, using iTunes 11.0 or later the following steps will let you replace the new version of an app in your iTunes library with an older version. Once you have “downgraded” the app in your iTunes library, you can resume the “Steps to Restore an Old App Version” process above.
 
  1. Open the recycling bin, or wherever you stored the old IPA files.
  2. Find the IPA file for the old version of the app.
  3. Open iTunes.
  4. Drag the .IPA file into the “Library” section of iTunes.
  5. Click “Replace” when iTunes warns you that you are about to replace a new version of that app with an old version.
  6. Resume the process above.