Posts in Technology (67)

Ten Things You Need to Know About iBeacon

You may have recently heard a lot of buzz about iBeacon and Bluetooth Low Energy. At ReignDesign, we're helping our clients make sense of this new technology, and how it can be used to making great location-aware mobile experiences.


Kirsten Osolind, President and COO of re:invention consulting, recently said  “Beacon technology will improve the way consumers use smart phones and transform numerous industries by solving the indoor geo-location challenge. It has great potential to facilitate better mobile payments thereby disrupting the whole credit card ecosystem because of its range.”

We're compiled 10 interesting facts that you need to know about iBeacons.

1. iBeacons are tiny

iBeacons are very small. To give you an idea, here's a Lego man holding an iBeacon in the ReignDesign office. This means it's easy to hide an iBeacon discreetly in a store or at an event.

2. iBeacons have very long battery life

iBeacon uses the "Bluetooth Low Energy" technology. Low energy means that a iBeacon can run off a single standard lithium battery for 1-2 years. You don't need to worry about an external power supply.

3. Most modern smartphones support detecting iBeacons

iOS devices including the iPhone 4S, 5, 5C and 5S, the iPad 3 and later, iPad Mini, all support iBeacons. iBeacon is Apple's brand name for this technology, but iBeacons work fine with Android devices too! Many Android devices running Android 4.3 or later detect iBeacons, including the Samsung Galaxy S3/S4/S4 Mini, Samsung Galaxy Note 2/3, HTC One, Nexus 4, 5 and 7.

4. You don't need an internet connection

iBeacons use Bluetooth. A device with Bluetooth switched on can detect iBeacons in range and pop up a notification or unlock content, even if there is no Internet connection. Of course, the content needs to be already included in the app. If there is Internet available, the app can do more advanced things, such as pulling live content from a website in response to detecting an iBeacon.

5. iBeacons work well indoors

Most smartphones use "assisted GPS" to determine a user's location. This uses a combination of the satellite GPS system, and local wifi and cellular tower signals to obtain a location. This isn't ideal: GPS only works outdoors, and wifi/cellular location is very rough. AGPS can tell you you are in a shopping mall, but not which store you are in. iBeacon is perfect for this scenario. Each iBeacon has a range of about 30m. For example, in a shopping mall, an iBeacon could be placed above the entrance to each store. A shopping mall app could then tell the user which store they are located nearby.

6. Big brands are already using iBeacons

Major League Baseball (MLB) is the major league professional baseball organization in the US. MLB first installed iBeacon technology at Petco Park and Dodger Stadium. By Opening Day of the 2014 season, 20 ballparks were equipped using iBeacon technology. Baseball fans can use the iBeacons with the app At The Ballpark.

Westpac Banking Corporation is a major Australian bank. They're rolling out iBeacon technology in branches. iBeacon will be used to send customers alerts with special offers and other incentives on their device when they are in or near a branch.

Apple themselves are also finding ways to use to offer targeted information to passing users via app notifications or in-app content. Recently, Apple introduced physical iBeacons at its retail stores. Beacons are placed throughout the store and as a customer walks around, the beacons trigger messages to the customer’s iPhone. A customer can scan an item they want and pay for it from their phone using the Apple Store app; the app too uses beacon technology.

7. iBeacons need an app to work

An iBeacon simply broadcasts a number of identifiers. For example:

{ uuid = "74278BDA-B644-4520-8F0C-720EAF059935"; major = 65504; minor = 65505; }

Now if we want a user's device to do something interesting when this beacon is detected, like pop up a coupon for a store, or unlock a video, we need an app. If the user hasn't downloaded your app, they won't see your iBeacons. When the app is launched, it can register which beacons it is interested in, for example any beacons with uuid "74278BDA-B644-4520-8F0C-720EAF059935" could cause a notification to pop up.

8. When you get close to an iBeacon, you can pop open a notification, even if the app is not running

When a user with your app installs comes close to an iBeacon, your app is notified. What happens next depends if the user has your app open: If they don't have the app open, your app is launched in the background. You can still do certain tasks like popping up a local notification. unlock For example, imagine a restaurant installs iBeacons at the entrance to each store. Customers with the app installed can receive a notification when they arrive. In a more advanced scenario, the app could make a web request to check if there are any active promotions. Only if there is a promotion relevant to the current user would the app pop up a notification.

9. If your app is running, you can unlock content based on beacon location

If your app is running, you can not only detect the location of beacons, but even see how far away they are using "ranging". This opens up many exciting possibilities. For example, imagine guests at an auto show. Each car model has an iBeacon attached. When guests holding an iPhone or iPad approaches the car, a video in the app can automatically play.


10. Choose a partner who understands this technology.

iBeacons are a new technology, and it pays to choose the right partner. ReignDesign is already working with a number of brands and agencies in Shanghai and around the world in deploying iBeacon-enabled apps. We have iBeacons in our office right now, and we're happy to give you a demonstration of this exciting technology. Get in touch today!

Does your app contain, display or access third-party content?

Apple have recently added a new question into the iTunes Connect flow when submitting a new app, or an update to an existing app.

"Does your app contain, display or access third-party content?"

If you answer "No", you can continue with the submission, if you answer "Yes" you are asked a further question, "Do you have all necessary rights to that content or are you otherwise permitted to use it under the laws of each App Store territory in which your app is available (for example, fair use).

If you answer "Yes", you can continue, if you answer "No" you are shown a warning, and a link to the trademarks section of the App Store Guidelines.

This doesn't appear to be any new policy on Apple's part, but we can guess that Apple is planning to enforce the guidelines more strictly in future, in particular guideline 8.5:

8.5 Apps may not use protected third party material such as trademarks, copyrights, patents or violate 3rd party terms of use. Authorization to use such material must be provided upon request.

This seems most likely to affect apps which use the brand names or logos of other companies, for example apps which show fashion products, sports teams, TV network logos, etc. Be prepared to submit written documentation that you have the right to show such content, even in the past Apple has not rigorously required this.

Customizing individual share services in a ShareActionProvider on Android

In theory, sharing on Android is simple. Because of the system of Intents, you can prepare your shareable content, like an image, or text, and then easily show a list of installed apps which are able to handle this type of content. For example, if you’re sharing a photo, apps like Instagram, Twitter and the Gallery app will be available in the list. No additional coding is required for each sharing service!

  1. Intent i=new Intent(android.content.Intent.ACTION_SEND);
  2. i.setType("text/plain");
  3. i.putExtra(android.content.Intent.EXTRA_SUBJECT,"My cool app");
  4. i.putExtra(android.content.Intent.EXTRA_TEXT, "Here’s some content to share");
  5. startActivity(Intent.createChooser(i,"Share"));

But what if you want to customise the content depending on the chosen service? For example, if the user chooses Twitter you might want to shorten the text you’re sharing. Facebook on Android also has a long-running bug that means it won’t share text/plain content shared via an Intent… it only works for links.

Perhaps we’d like to use some different logic when our user clicks Facebook, for example using the Facebook Android SDK we could invoke an Open Graph sharing dialog.

Unfortunately, this is not easy. If you’ve followed the Android tutorial on adding an easy share action to the action bar then you’ll have a ShareActionProvider which creates a share button and dropdown for your action bar.


The documentation is rather contradictory about whether you can customise ShareActionProvider’s behaviour. There’s a promising looking listener called setOnShareTargetSelectedListener, described here:

Sets a listener to be notified when a share target has been selected. The listener can optionally decide to handle the selection and not rely on the default behaviour which is to launch the activity.

So we might think to check the type of the intent in the listener, and run some custom behaviour for certain share types.

However the documentation goes on to say that

"Modifying the intent is not permitted and any changes to the latter will be ignored. You should not handle the intent here. This callback aims to notify the client that a sharing is being performed, so the client can update the UI if necessary."

The return result is ignored. Always return false for consistency.

It turns out if we try to add some custom code in setOnShareTargetSelectedListener, the custom code is run, but the standard share intent is also launched :(

Luckily since Android is open source, we can dig around in the source code to find out what’s going on.

Here’s the source code for the ShareActionProvider class in the v7 support library on Github.

Notice the class at the bottom ShareActivityChooserModelPolicy, which calls the listener, but then returns false regardless. Returning true from this method would allow us to handle the intent, without invoking the default behaviour.

  1. private class ShareActivityChooserModelPolicy implements OnChooseActivityListener {
  2. @Override
  3. public boolean onChooseActivity(ActivityChooserModel host, Intent intent) {
  4. if (mOnShareTargetSelectedListener != null) {
  5. mOnShareTargetSelectedListener.onShareTargetSelected(ShareActionProvider.this,intent);
  6. }
  7. return false;
  8. }
  9. }

We can’t easily subclass ShareActionProvider to override this behaviour, but what we can do is make a complete copy of the class and implement our own custom behaviour!

Copy the entire source file into your app, changing the package declaration at the top, and optionally the class name, for example to RDShareActionProvider.

Implement a new listener

  2. private OnShareListener mOnShareListener; //also need to add getter and setter
  4. public interface OnShareListener {
  5. /**
  6. * Called when a share target has been selected. The client can
  7. * decide whether to perform some action before the sharing is
  8. * actually performed OR handle the action itself.
* * @param source The source of the notification. * @param intent The intent for launching the chosen share target. * @return Return true if you have handled the intent. */ public boolean willHandleShareTarget(RDShareActionProvider source, Intent intent); }

Time to re-implement the ShareActivityChooserModelPolicy using our new more powerful callback.

  2. private class ShareActivityChooserModelPolicy implements OnChooseActivityListener {
  3. @Override
  4. public boolean onChooseActivity(ActivityChooserModel host, Intent intent) {
  5. if (mOnShareListener != null) {
  6. boolean result = mOnShareListener.willHandleShareTarget(
  7. RDShareActionProvider.this, intent);
  8. return result;
  9. }
  10. return false;
  11. }
  12. }

We're in the home straight! Now we need to change the reference in the menu XML to our new class name.

  1. <item
  2. android:id="@+id/action_share"
  3. android:title="@string/menu_share"
  4. android:icon="@drawable/ic_action_share"
  5. myapp:showAsAction="always"
  6. myapp:actionProviderClass="com.myapp.RDShareActionProvider"

Finally we can implement our listener. We can check the package name of the intent, each sharer will have a different one, depending on the app. For Facebook, it’s com.facebook.katana.

  2. mShareActionProvider.setOnShareListener(new OnShareListener() {
  3. @Override
  4. public boolean willHandleShareTarget(RDShareActionProvider source, Intent intent) {
  5. if (intent.getComponent().getPackageName().equalsIgnoreCase("com.facebook.katana")) {
  6. //just showing a toast for now
  7. //we could also manually dispatch an intent, based on the original intent
  8. Toast.makeText(self, "Hey, you're trying to share to Facebook", Toast.LENGTH_LONG).show();
  9. return true;
  10. } else {
  11. return false; //default behaviour.
  12. }
  13. }
  14. });

Finally, we have control over individual sharers!

Haikus from WWDC session transcripts

So, a lot of you

I'm sure are familiar with

Grand Central Dispatch

- Hidden Gems in Cocoa and Cocoa Touch, WWDC Session 228

At ReignDesign we're a big fan of AsciiWWDC, a great resource for reading and searching the full-text transcripts of Apple's Worldwide Developer Conference session videos.

And there's something a little poetic about the way the transcripts are listed. This inspired some late-night hacking creating wwdc-haiku, a simple Python script which, given a session number, attempts to scan the transcript of a single session for possible haikus (that is, sentences with a 5-7-5 syllable pattern).

$ ./wwdc-haiku 228

And what happens is 
you choose that and you see a 
window like this pop 

So, it's going to 
look very similar to 
the last example 

And actually 
I'm backing it this time by 
a dictionary 

So, a lot of you 
I'm sure are familiar with 
Grand Central Dispatch 

It's just one of those 
things that it takes a while to 
get into your head 

I think the two most 
useful and interesting 
ones are max and min 

It's returning a 
Boolean whether or not 
it was successful 

So, was that that was 
pretty fast, but I think we 
hit everybody 

Yes, we know our haikus won't pass muster with any Japanese poetry scholars... but do clone the code from Github and have fun!

What can you do with

these? Well, in Jay's Donut Shop

I had this problem

- What’s New in Core Location, WWDC Session 307

Our first adventure with Windows Phone: Porting Bible Promises

For mobile app developers, it's been a two-horse race up to now: iOS versus Android. We've been keeping an eye on the progress of Windows Phone, and there are finally signs that it may be solidifying it's position in third place, it's edged up to a 3.7% market share worldwide according to a recent survey.

The time seemed right to dip our toes into the Windows Phone ecosystem, so we decided to port one of our existing apps, Bible Promises, to Windows Phone. Why choose Bible Promises? First, Bible Promises has a large community of active users on Facebook, Twitter, Pinterest and Tumblr. Second, as a content-based app rather than a game, it would allow us to explore the native UI elements provided by Windows Phone.

Our first step was to identify a mininum viable feature set. Bible Promises for iOS and Android are both mature products which have gained a lot of features over the year. We didn't necessarily need to port everything over on the first version. In Basecamp, we brainstormed on the most important features:

Screen Shot 2013-08-09 at 11.28.48

We also decided which features we should include that would make the app work well in the Windows Phone environment. At the Bibletech conference earlier this year, I spoke with Matthias Shapiro, a Windows Phone evangelist, and asked him one one feature he would add to an app to make it feel native on Windows Phone. He recommended adding a Live Tile. We decided to use the Live Tile to promote the Daily Verse, one of the most popular features of our iPhone and Android apps.


The next step was to get our development environment set up. This was a little painful: we're used to working on our Mac laptops, so had to resurrect an older PC, install Windows 8 on it, and then install Visual Studio Express. Despite a lot of messing about with settings, we weren't able to get the Windows Phone Emulator to work, so all of our testing had to happen on a device.

For a device, we purchased the excellent value Huawei Ascend W1 from Taobao. We had no problem getting this registered as a development device and running our apps on it.

For the app UI, we decided to follow the Windows Phone design guidelines as much as possible. This meant that the app has a distinctive feeling from our iOS and Android apps. We used the Panorama control to allow the user to swipe between verses. To ensure that the app still "felt" like Bible Promises, we carried over the colors and fonts from our existing apps, such as using Georgia as the main font. This ensured the final app felt like a Windows Phone app, but was still familiar as Bible Promises.



Finally, we submitted to the Windows Store! The app is now available to download. There's a trial version which allows you to sample the first half of the category list, the full version is just $0.99 or equivalent.

We'd love to hear your feedback if you have a Windows Phone. Please get in touch!