ChildFlare Part 2 – Creation

Continued from Part 1

As App Creators, we believe in keeping our tools sharp and exercising our creative passion for solving real world problems with Mobile Apps.  So with our registration to AngelHack Beijing in one hand, and an idea that needs a solution in the other, the stage was set for ChildFlare to become real!

We sent a team of two to AngelHack – developer & designer in partnership, and as per the rules of the Hackathon we didn’t start any code until the start of the Hackathon.  We knew in advance we would be making judicious use of our favourite Backend-as-a-Service and possibly too.  Recently we’ve been experimenting with using the two services together and they’re a formidable combination.  So we had an idea of the app architecture, but still had a lot to figure out.


Kicking off our collaborative design process, we talked through the scenarios, use cases and goals for the users of the app.  Simplicity of design was our ultimate goal, and so we were happy with the evolution of the design when it evolved from 3-tabs, to 2-tabs and finally to throw away the tabs all together.  As the Child is the centre of the world for the Parents (and hopefully the carers too) we made the Child the centre of the design.

The structure we arrived at was:

  1. Main Page
    1. List of all Children:
      1. My Children, who they’re currently with, and a button to phone the current carer.
      2. Children I care for as a carer, button to call the parent, and when I last cared for this child
      3. Children I’ve been asked to care for, Yes / No buttons to accept or reject
  2. Child Detail Page (for My Children)
    1. Care History – who had my child & when.
    2. Authorised Carers – who do I expect my child to be cared for by.  From here you can invite other carers, or deauthorise a carer.
    3. Edit – update my child’s photo, name or other details

Adding in some out-of-the-box User registration pages from the Parse SDK and we were set.  With the design set, the Designer can get on with producing the graphic design, while the programmer can start creating the code.


Talk to many programmers and you’ll sometimes hear discussion about Top-Down and Bottom-Up design.  There are benefits and drawbacks for both, and I rather see them as different modes of operation.  With 24 hours to build a solution I knew I would need to jump between these two modes, and with any long session it’s often good to switch mindsets anyway – a change is as good as a rest they say!

In order to make it easy for the organisers to verify the ‘no-prior code’ requirements – I set up a GIT repository locally on my laptop in order to have a full version history, along with the ability to backtrack whenever I end up in a rabbit-hole…  The other benefit of this is it makes it super simple to retrace my steps and see how I spent my time!

  1. (25 mins) New Xcode project, integrate Parse SDK, basic Storyboard layouts.
  2. (25 mins) Parse login / signup form customisation.
  3. (50 mins) Bottom up support for the iBeacons.  Getting ranging and region entry/exit working.
  4. (20 mins) Each child would be a unique iBeacon, and so the interface layer needs to abstract away the details and just provide inside/outside and alerts for the unique identifiers.
  5. (15 mins) Basic UITableView to show the list of children.
  6. (30 mins) Make a start on building the ‘Add Child’ function that would find an unallocated tag and create a new object on to represent that child.
  7. (30 mins) Finish create child function, and create relationship to the User – Parent only for now.
  8. (10 mins) Query parse to get a list of Kids and populate the tableview.
  9. (40 mins) Create sessions on for each period of time that a child is with a user
  10. (2 hours 20 mins) Track the current & most recent carer, force updates in real time based on beacon state changes, debugging and making sure the previous items are good.
  11. (55 mins) Push Notification support
  12. (40 mins) Testing / fixes
  13. (50 mins) Child Detail page

At this point we had a barebones working product that we could test.  I decided I would be more productive by taking a break, so I went home to catch some Zs.  Throughout the night I had woke with a flash of inspiration, and achieved the following steps by the morning:

  1. (30 mins) Add support for photos to the Child Detail Page. Search for other users and invite them as a Carer.
  2. (30 mins) Apply the design elements from the designer to the Children List.
  3. (30 mins) Improvements to the underlying data model
  4. (10 mins) Simplified the logic for detecting a beacon leaving the area.
  5. (25 mins) Receive Carer invitation.
  6. (25 mins) Bug Fixing
  7. (30 mins) Edit child, apply design theme to Child Page
  8. (30 mins) Add take/upload photo function for Children
  9. (10 mins) Buttons to call the current carer
  10. (20 mins) UI Improvements.  A lot of the pages were relying on asynchronous parse calls, so I added a subclass for UITableViewController and UIViewController that would enable me to overlay an activity indicator easily while the operation was progressing.  Then all my custom view controllers derive from one of those new superclasses.
  11. (40 mins) Testing & fixing
  12. (15 mins) UI Flow improvement for finding another user
  13. (15 mins) App Icon added, make the main page buttons for Accept/Reject invitation work, main page Call Carer buttons work

Now to head back to TechTemple to complete the project, we have around 3 hours left, but we’re in very good shape now!

  1. (20 mins) Customise the login / signup page further
  2. (40 mins) Testing & working with the designer on the iconography
  3. (1 hour) Improve the session syncing between the beacon manager and the network
  4. (30 mins) Cleanup, test/fix and submit

Total Development time: 17 hours 10 mins


There were almost thirty teams in total, and we had only 2 mins to present each product.  With such little time it’s always going to be a bit of a crapshoot to get the idea across and demonstrate the quality of the product you built, so we were pleased with a third-place finish.  We were also very encouraged by the number of demo-show attendees who hoped that we would pursue this idea to commercial reality.  Hackathon results are nothing compared to winning in the marketplace – and if we can demonstrate sufficient traction we’ll definitely build this.  So – let us know in the comments, should we build this?  Get your friends to tell us too.  Like our Facebook page and tell us there too!  Make some noise and we’ll make ChildFlare happen.

Since this relies on a hardware product we need to invest in the tooling and development of appropriate child-friendly iBeacon tags – if this was just an App product then for sure it would be in the AppStore approval queue already!

Featured image is “Father Holding Child Hand” by David Castillo Dominici, from

About ikuramedia

ikuramedia - The App Specialists