Is the AppStore broken? Here are some indications

It looks like the Christmas break did something to the AppStore. First, the iTunes Connect was pretty much closed over the Christmas period, which is understandable. After iTunes Connect came back online again the review seem to take longer and the correspondence is not working well.

Here are four cases that indicate that the AppStore is broken.

1. We notices a spike of new users for our PinPoint app. Additional users did hit our sever and we know for sure that they are new users. However, the AppStore Trend Reports did not show any increased download at all. We are talking several hundred downloads that might have been missed. Since the daily trend reports may differ from the *real* download numbers we need to wait for the financial reports to see whether there is a problem with the AppStore operation. If the financial reports will not show the additional downloads then Apple needs to explain to us how that is possible.
   
   
2. I received an email that our new app is Ready for Sale. After login into the AppStore it shows the app still under Review. (Remark: It is now set to ready for sale. More than 2 hrs after I received the email from Apple sayig it was ready. But the app is still not in iTunes.)
   
   
3. Another app is shown as rejected. However, there is so far no email from Apple telling us that it was rejected or the reason why the app was rejected.
   
   
4. I updated some screen shots for an application several days back but in iTunes it shows something different.
   I Uploaded three images and all three are different. However in iTunes it shows only two different images and one is shown twice. Not happy with that because our customers might think we are idiots putting the same screen in there twice.

iPhone and Android can tell when you arrive

Location apps that tell people "when" you arrive not just where you are.

When we tell friends in non-technical terms what we are doing at jTribe we usually say something like:

" We make applications that allow your partner to know when you are coming home".

The response we then get is:

" That means I don't have to call or message constantly where I am and what my ETA would be? I could use that."

jTribe has finished the first application that solves the problem of "personal ETA notification" (Has anyone a better term for that?).

The application is called "Going Home" and it is based on the problem many families have: Someone is waiting at home and would like to know when you arrive.

The underlying User Intention

#1: I want to meet someone at their place.
#2: I want to let them know how long before I arrive.

The 4 Ingredients
To solve the problem of letting someone automatically know when you are going to arrive we need four ingredients:

1. Destination - of the place we want to go (e.g. home)
2. Contact - details of the person waiting for us at the destination
   (e.g my partner waiting at home)
3. Current Locations - where we currently are
4. Notification - let them know
   

Hey, the iPhone or Android G1 is providing exactly what we need. It has an Address Book with contacts. The contact often have an address which we could use as destination. The GPS in iPhone or Android phone provides current location. Great, almost done.

Stop, we still need a Solution for Notifications
TXT/SMS would be good for that because it a great mean to notify people instantly. Email would work too but does not have the instant characteristics of TXT/SMS. We settled for a combination of Email and TXT/SMS. At the start of the trip an Email is used to send a shared map link to the person who is waiting. TXT/SMS messaging is used to notify the person when you close to their place.

Unfortunately, the iPhone does not let you send TXT/SMS programmatically. Yes, it's true Apple still hasn't included it in their last iPhone 2.2 update. We thought there is no point waiting until Apple may or may not include an SMS API. So we had to integrate with a TXT/SMS gateway to send messages on behalf o the user. The issue with that is that these gateways are not free and someone has to pay for each SMS that gets sent. But without SMS the whole solution would be pretty much pointless. On the Android phone it would be possible to let the phone send SMS.

The Frontend
The primary frontend for the person that is travelling is either the iPhone (Android G1 is coming soon). As long as the iPhone application is running in the foreground it can constantly submit the current location to the backend server.

SMS will not be sent from the iPhone but from the backend server.

The person who is waiting has a different frontend. They receive an email with the shared trip map. They can then use the web browser to live-track the traveling person.
They will also receive an SMS when the traveling person is close enough.

The Backend
One key component of the solution is our FirePin platform. We use it as a backend to store all the user's locations so it can be shared with the person waiting. It also allows that person to track progress of your trip in real-time. (Sample of a shared trip)

FirePin Recap: The FirePin platform that allows recording and tracking of locations via the iPhone and Android G1 (and Symbian S60 soon). Basically, FirePin is a generic platform for location tracking and trip history. Because people store quite a number of trips on our FirePin servers we could almost call FirePin "personal GEO location hosting". (Rem: currently we got almost 2 million GEO locations in the FirePin database).

With the limitation of the iPhone we decided to extend the backend to include Notification services. Based on the locations that are constantly submitted to the FirePin server the service calculates the remaining distance to the destination. When a distance is close enough it will send out the TXT/SMS message to the person that is waiting.

Did I mention that the backend is written in Ruby On Rails.

The Integration
Integration between the iPhone and the Ruby On Rails backend is done via JSON and REST. Check out http://jtribe.blogspot.com/2008/11/json-and-restful-web-services-on-iphone.html

The End?
No this is not the end. It's the beginning of a series of apps from jTribe. Going Home is just the start. We have many ideas of location-aware applications that are getting more micro-social .

Pushed out a new iPhone Travel and Location app

Yes, we where busy recently. Daniel got his Google phone and Armin did work on some more iPhone apps.

As a result we are happy to announce that "going home for Christmas" has been released into the AppStore today.

Here is what the app does:

Are you on a road trip and want to let someone know that you are close by.

This app can automatically send a TXT message when you are approaching home.

Driving home from work or traveling to visit your family or friends? Let them know that you are coming and where you currently are.

Allow them to see your travel progress in real-time.

Going Home for Christmas gives peace of mind to the people waiting for you.

FEATURES:

- Simply select a person from the Address Book

- A TXT/SMS message is sent when you are close enough

- An Email is sent so the person can track you live via the Internet

- Uses the location services on your iPhone (GPS)

- The distance to the persons address will be constantly calculated and once you are closer than 5 km (3 miles) a TXT message will be sent

NOTES:

TXT sending is included in the price for this application. No additional costs for TXT/SMS will be charged by your phone provider.

This application relies on the information in your Address Book. It uses the home address of the person you choose to visit. If they have a mobile number it will use it to send them a notification TXT/SMS message.

JSON framework with iPhone SDK 2.2

This is something that has cost me several hours after I upgraded to iPhone SDK 2.2. I have also documented it in the iPhone Discussion Forum but here is a brief summary.

If you going to use the JSON framework with the iPhone SDK 2.2 then there will be some problems. I could no longer link the framework to my application. For some reason Apple has changed the code signing behaviour. To get around it you need to add the JSON framework source code to your XCode project. 

1. Get the source code from:

svn checkout http://json-framework.googlecode.com/svn/trunk/ json-framework-read-only

2. Then copy that source code into your project directory (or use XCode add existing file...). 

3. Where you used :

#include <JSON/JSON.h> 

now you have to use:

#include "JSON.h"

and (as Dom pointed out)

#import "SBJSON.h"
#import "NSObject+SBJSON.h"

#import "NSString+SBJSON.h"

4. Build should be OK now.

Check out also http://jtribe.blogspot.com/2008/11/json-and-restful-web-services-on-iphone.html for more JSON / iPhone information.

Sending MMS with Android

Following on from my last post about saving a view as an image, today I want to demonstrate how to send this image via MMS. We used this technique in our application, PinPoint to send out maps via MMS. 

I have previously written about how to send SMSs with Android intents and while sending MMS via intents goes to the same application, the intent that needs to be constructed is quite different. The intent requires the following items to be set:

• the action set to be ACTION_SEND
• the mime type set to image/*
• a Uri extra inserted with the key Intent.EXTRA_STREAM
• optionally some text body with the key sms_body

Intent sendIntent = new Intent(Intent.ACTION_SEND); 

sendIntent.putExtra("sms_body", "some text"); 

sendIntent.putExtra(Intent.EXTRA_STREAM, Uri.parse(url));

sendIntent.setType("image/png"); 

The url being passed to the Uri.parse method should be of the form used to access the media store such as content://media/external/images/media/23. The previous article of views and images returns a url String that can directly be used by this MMS intent. 

Saving a view as an image with Android

Our Android application PinPoint can send map images via MMS and email. We used the following technique to be able to convert the MapView into an image that could be used across applications. 

Firstly create a Bitmap object with the appropriate width and height of your view, along with a configuration. RGB_565 seems to work just fine for the MapView canvas.

Bitmap image = Bitmap.createBitmap(view.getWidth(), view.getHeight(), Bitmap.Config.RGB_565);

Next create a canvas with the bitmap and pass that into the draw() method of the view. This will ask the view to draw it's contents onto the canvas and therefore the associated bitmap.

view.draw(new Canvas(image));

Next insert the image into the Media library. This returns a URL that refers to the stored image and can be reused across applications. In our case we could pass this URL to the MMS application to have it embed the image in a message.  I'll post some sample code of how to send this image via MMS shortly.

String url = Images.Media.insertImage(getContentResolver(), image, "title", null);

To test this in the emulator you'll need to setup an external storage device otherwise you'll see an error like :-

java.lang.UnsupportedOperationException: Unknown URI: content://media/external/images/media

First you'll need to create a storage image using the mksdcard from the tools folder of the emulator

mksdcard 10M sdcard.iso

Then when you start the emulator you need to pass the -sdcard parameter 

-sdcard /sdcard.iso

In my next post I'll write up how to send this image via MMS

Sending SMS using Android Intents

You've got an Android application and you want to send an email, sms and mms via your application. But you don't want to have to write a whole mail/mms/sms client. Thankfully Android provides a flexible way to forward responsibilities onto other applications installed on the device.

Android uses the concept of intents to enable applications to make requests for other applications to handle their tasks. For example, an application finds your location and wants to send it as a map via MMS. 

This can done by by constructing an Intent object, loading it up with the appropriate action, data and sending off to the operating system. 

Intent sendIntent = new Intent(Intent.ACTION_VIEW);

sendIntent.setData(Uri.parse("scheme://data"));

sendIntent.setType("mime/type");

sendIntent.putExtra("key", "value");

startActivity(sendIntent); 

Android then decides which activity can best handle this intent based on various attributes such as scheme (mailto, http) and mime type (image/png). 

If multiple applications could handle the intent (if you're sending an image), then you can even prompt the user to choose which application they want to use (email,MMS, IM)

startActivity(Intent.createChooser(sendIntent, "Title: ");

This all sounds too easy to be true. And it is. The reality is that in order to invoke mail,sms and mms I have needed to dive into the Android source code (thank goodness for Open Source!). I wanted to invoke each of these applications, filling in as much of the content as possible. The documentation for Intents even suggests this is possible to attach images, set subjects and body text. 

To invoke the SMS application via intents you have to do the following:

• Set the action to ACTION_VIEW
• Set the mime type to vnd.android-dir/mms-sms
• Optionally add any text by adding an extra String with the key sms_body 

Intent sendIntent = new Intent(Intent.ACTION_VIEW);

sendIntent.putExtra("sms_body", "The SMS text"); 

sendIntent.setType("vnd.android-dir/mms-sms");

startActivity(sendIntent);   

Android also enables you to send SMS directly using an API without bringing up the SMS application. However it is much more transparent to the user to allow them to see what they are sending and maybe add or edit before it goes out. Using Intents also means you can minimise the permissions your application requires.

Sending MMS and email is a much longer story which I'll get into in some later posts.  Stay tuned!