Friday, 27 June 2014

ExactTarget - the worst DX ever.

What is DX and why does it matter? DX stands for 'Developer Experience'. It refers to the experience that developers like me have when implementing, or integrating with, technical products or services. It matters because a product owner's failure to assist developers with implementation has some negative side effects.

Firstly, implementation may be slower than desired, with cost and time implications for client. Secondly, developers, particularly freelance or contract developers like myself, will actively discourage future clients from using the product again, and will instead hope that a competing product performs better. Thirdly, the client will also remember the bad DX and will try to avoid the product when next given the choice, perhaps in a new role at a different company. Finally, it will annoy some developers so much they might just blog about it in an attempt to save their kinfolk from a similar fate.

Enter ExactTarget. I was recently tasked with implementing their MobilePush product into an iOS and Android app. The documentation on how to achieve this was sufficient, and I had it up and running in basic guise within a day, managing to register devices for push notification and send messages to them. But then I started having problems. Firstly, I couldn't set up locations because despite my client paying for it it hadn't been enabled on their account. It took me about 1hr of head-scratching to first suspect this, and then to get confirmation of it took ET 14 working hours, and then another 4.5hrs to rectify. In total this is nearly 3 working days. When I was finally given access to locations I couldn't get them to work - my entry and exit message have never been received on either of my opted-in devices. 6 further working days later I am yet to get a satisfactory explanation as to why this is - have I done something wrong with the code? Am I doing something wrong with the messaging GUI? Is there something wrong at their end? Did they forget to switch something on? I have absolutely no idea, because every time I request help it takes hours, sometimes days, to get a response, and when the response comes it hasn't addressed the problem sufficiently, or tells me to do something I've already done. Then I have to respond and wait another Xhrs/days.

ExactTarget's non-support smacks of a company going through growth pains. Their technicians (the people that can really resolve problems) are probably not in the UK, and their Solutions Architects (the 'technical' people that we deal with) are probably unleashed onto customers and developers with rapid (insufficient) training and little actual technical ability/tools/permissions to troubleshoot for developers, leaving them hamstrung by cross-time-zone comms with their probably over-stretched under-resourced technicians.

I have little doubt that there's someone at ExactTarget who could probably understand and diagnose the problems I've been having within the space of a short phonecall. Unfortunately this isn't going to happen as a) they don't do this and b) this is my last day on this contract and I'm having to leave my client with what I believe to be a correct and working implementation but with little evidence that this is the case. I wish them luck getting the outstanding issues resolved.

Monday, 23 June 2014

iOS push notification prompt no longer appearing

Today I was having trouble getting my app to prompt me for push notification preferences even when uninstalling and re-installing. It seems that the OS remembers these preferences (and others) for 24hrs even after deleting an app, so the only way to circumvent this and pretend you're on a completely clean install is this:
  •  Delete your app from the device.
  •  Turn the device off completely and turn it back on.
  •  Go to Settings > General > Date & Time and set the date ahead a day or more.
  •  Turn the device off completely again and turn it back on.
  •  Re-install app

Friday, 23 May 2014

ExactTarget MobilePush setObjectForKey: object cannot be nil (key: app_version)


Recently I've been integrating the ExactTarget MobilePush SDKs into the Android and iOS code running behind my Cordova/Phonegap app. It hasn't been plain sailing due to documentation that isn't too brilliant, slow comms from the SalesForce team, and technical hurdles that are difficult to find answers to.

One problem was a crash when running my iOS app with the newly-integrated ExactTarget MobilePush iOS SDK. I kept getting this error:

Uncaught exception: *** setObjectForKey: object cannot be nil (key: app_version)

At first I thought this may have arisen because my app was yet to be provisioned by ExactTarget, and it was their code causing the error, and perhaps it might fix itself once I had received notification that I had been provisioned. Finally after a couple of days I received this notice, but alas the error persisted.

After more research I discovered that my app didn't have an Info.plist entry for "Bundle versions string, short" (or CFBundleShortVersionString in the source). Once I added this my error disappeared!

Wednesday, 21 May 2014

Retrieve the SHA1 fingerprints of the Android Debug Key

Note to self. How to retrieve the SHA1 fingerprints of the Android Debug Key using a Terminal window:

keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore -list -v

And the output looks like this:


Tuesday, 20 May 2014

Git checkout error: Unable to unlink 'plugins/...'

Had a strange git error today when finishing a GitFlow release on my PhoneGap/Cordova app. It was occurring when it seemingly tried to checkout master, and then would fail, leaving a whole heap of dirty unfinished work in my develop branch.

So I hard-reset the dev branch and attempted to checkout master manually. Same error - 'unable to unlink' and then lots of references to a certain geolocation plugin in the /plugins/ dir. Looking in detail at this directory it was clear that it had different ownership to all the other dirs. Everything else was owend by edpitt, but this was owned by 'root', for some unknown reason. So I ran a 'sudo chown -R edpitt /plugins/org.apache.cordova.geolocation' to turn it back to the correct ownership.

Once this was complete I was able to checkout master with no errors, and so attempting a GitFlow release this time proved successful.

Tuesday, 13 May 2014

Android 4.4.2 tap event registering when unhiding element

This is weird. I have two images of a heart, one grey, one red. I use them to allow a user to 'favourite' an item in a list. When the grey heart is tapped I hide it and show the red heart. When the red heart is tapped I hide it and show the grey heart. Simple huh? You can see them in this pic here:



The code looks something like this:
       
      $( ".greyHeart" ).bind( "tap", function( event ){
                    
              $(this.parentNode).addClass('favourited');
              $(this.parentNode).removeClass('notFavourited');
                    
               //store data in array in local storage
           
        });

       $( ".redHeart" ).bind( "tap", function( event ){

              $(this.parentNode).addClass('notFavourited');
              $(this.parentNode).removeClass('favourited');
          
             //remove data from array in local storage

        });

This all works brilliantly across my desktop browsers, iOS and most Androids. Except 4.4.2.

In 4.4.2 it seems that the tap event is detected on the grey heart and then again the tap event is detected on the red heart too when it appears under the user's finger. The user sees the heart turn red then immediately grey again.

To get around this odd behaviour I had to change my code to immediately unbind tap events on detecting a tap, and then rebind them after a small delay.