The Issue

As I was working on my first iOS app, I came across a weird problem. I have barely implemented anything, just a few ViewControllers, TableView and a few other UI elements.

When I was running the app, I noticed that sometimes, texts would disappear from buttons, labels and TableView cells.

The Search for answers

This issue appeared random and I could not find a single thing that would cause it in my code.

After some digging around the Internet, I found a few people who reported some UI issues but not like what I was experiencing. Even though the issues described were different, I attempted the proposed solutions — fixing some UIConstraints, removing and re-adding elements from Storyboard and removing and re-adding @IBOutlets.

That did not fix my issue.

The Solution

In a desperate move, I decided to delete my Storyboard and create a new one, not before selecting all elements within it and hitting Command-X to cut them and then paste everything back to the new board.

Then I just reconnected the outlets and re-added all my custom Classes to the elements.

I ran the app again and MAGIC!

Everything was working fine!

The Lesson

I don’t know exactly what screwed up my Storyboard, maybe I was deleting and renaming things in the wrong way, maybe it was just Xcode messing with me. Whatever the cause, my point in this blog post is that keep in mind that if you are working with Storyboards, you don’t always see what’s going on behind the scenes. And if you encounter issues, especially UI issues, and you don’t see a reason for it — keep in mind that you may just need to delete your Storyboard and start again.

When I first saw the HaloBack on Kickstarter, I immediately backed them.

I needed a new screen protector anyway and the concept seemed really cool — a screen protector that gives you a virtual “back” button in the space near your iPhone’s home button (like they have on all Android phones).

What it does is “transmit” your tap from the bottom part of the screen to the top left corner where most apps place the software “back” button.

When I backed them in November, the said it will be delivered by Christmas. That did not happen and I only got the unit in the end of January. I don’t hold that against them, I never expect crowed sourced projects to ship on time.

The Packaging

I received the product in my mailbox in an unmarked envelope from Singapore. When I opened it, I saw the screen protector package inside.

The package was fairly professional, it had a nice design, much nicer than most of those cheap screen protectors you can find.

Inside there are clear graphic instructions on how to apply the Protector to the phone.

I must say, I was very impressed with the packaging, it was better than I expected.

Installation

I had the “pleasure” of installing a few screen protectors in my life time.

It was always frustrating to say the least.

Making sure the sticker is aligned correctly, and that there are not dirt particles before placing it.

HaloBack were cleaver enough to include 2 small stickers that you can use to anchor the Protector in place once you properly align it. I did not consider this method in the past and I was more than happy to have at least that frustrating part taken cared of.

As expected, they also included a microfiber cloth and a plastic card to extract air bubbles.

This was by far the easiest installation of a screen protector I have ever done.

The Actual Product

After I finished the installation I quickly jumped into testing the virtual “back” button.

The first thing I noticed is that the screen felt a little hard to swipe my finger on.

It is hard to explain the feeling but it felt as if when I swipe my finger is “sticking” to the screen.

I was willing to ignore that for now, thinking it might just take some getting used to.

For my first test, I went into the iPhone’s settings app and on to one of the sub menus from there.

When I tapped the virtual button it immediately responded and the screen went back to the previous one.

When I tested it a few more times I found mixed results but after a few tries I got the hang of it and it seemed to work properly.

The Issues

The first, more serious problem, was that tapping the top part of the screen directly does not always respond. I have to tap multiple times for the tap to register properly.

This is truly annoying and probably caused by the mechanics behind the transmission of the virtual back button.

The 2nd issue I have is that the virtual back button is slightly too sensitive, making any slight slide of your finger, on the area left of the home button, activate the back button unintentionally. This can be very frustrating when you are in the middle of something that you don’t want interrupted. (Like writing a blog post on the Medium app — true story! )

The last thing is only relevant for people who use iOS with an RTL interface, making all software “back” buttons appear on the right instead of left and thus, making the virtual button completely useless.

In Conclusion

The HaloBack is a very promising product. They gave allot of thought and care for the packaging and installation. The actual product is a very cool concept but until they fix the issue with tapping the top part of the screen directly, I say wait on buying it for now. I am definitely waiting for version 2.

Note: I am not a Firebase expert, I just got into it while working on an iOS app. I write this article after struggling to find a way to implement some core social network app concepts such as “posts”, “likes”, “followers” and so on.

Introduction

As someone who used to work with SQL databases, switching to Firebase’s realtime database model was extremely weird.

I base allot of the information here on this post on the Firebase blog: https://firebase.googleblog.com/2015/10/client-side-fan-out-for-data-consistency_73.html?m=1

The basic concept

Firebase doesn’t use tables, rows and columns. Instead they use a big JSON file that has “nodes”. You write \ read data by supplying the path to the node you want.

Like the post on the Firebase blog mentions, you need “fanout” your data to multiple locations in the JSON for easier read access.

The concept is strange to someone who is used to SQL. In SQL you simply reference a key to a key in another table. In Firebase you have to duplicate the data to all the locations you need.

So for example, if your app uses hashtags in posts and you want the ability to show all posts for a specific hashtag, you will also have to duplicate each post a user submits to a “hashtags” node under each hashtag’s sub node.

Hashtags: {
 <hashtag_id>: {
  name: "MySuperCoolHashtag",
  posts: {
   <post_id_1>: {
    // your post data
   },
   <post_id_2>: {
    // your post data
   }
  }
 } 
}

What about Likes?

Likes are handled similarly to posts. You need to keep a record of the “like” all the places you may need to use it, for example: viewing the list of people who liked a post or a “Notifications” section where a user sees who liked his posts.

To accomplish those 2 examples you will need a node structure like this:

PostLikes: {
 <post_id_1>: {
  <user_uid_1>: true,
  <user_uid_2>: true,
  ...
 }
},
Notifications: {
 <user_uid_1>: {
  <notification_id_1>: {
   from_user: <some_user_uid>,
   type: "like",
   for_post: {
    <post_id>: {
     // your post data
    }
    // add whatever else you need to know about this notification.
   }
  }
 }
}

The above notifications structure also allows you to store other types of notifications, not just “like” alerts, for example “comments” or “friend requests”.

How to count Likes \ Comments?

Firebase lets you count the number of children in a node by using:

snapshot.children.count

but when you have allot of data this may not be the best approach. Instead you should keep a “counter” in your posts node under each post id.

When creating a new post, set the value to 0. When someone likes a post, increment the counter by 1.

You can use Firebase’s “Transactions” to do this.

Follow Functionality

For handling a “followers” type functionality, you will need at least 2 separate nodes: “followers” and “following”.

Separating the follower-following relationship into 2 separate nodes helps with accessing this data when you want to get the list of followers for a user or a list of who this user is following.

Just as with posts, when a user follows someone, you need to update this user’s following node and the target user’s followers node.

Conclusion

As you can see, in Firebase, data duplication is key for handling data in different ways. Think of a node in the db as a “View” in your app. If your app needs to display some data in a certain way in one place and another way somewhere else, that means you need to duplicate your data to multiple nodes.

Like I mentioned, this sort of thinking goes against everything we know about SQL but this way makes sense in Firebase, as “write” operations are considered cheap and “read” is more important to provide your users fast access to data.

I hope this post helps you, if you have any questions or if you are doing something differently please share it with me in the comments!

Problems connecting to the internet on iOS8

Today i upgraded my iPhone 5 to the latest OS by Apple — iOS8.

I notices several problems regrading internet connectivity — the first of which was when the phone rebooted after installing the OS — i could not connect to iCloud to restore my settings.

After that, i noticed several apps that also had problems connecting to the web, most notably Safari and Waze.

After digging around i found the problem! I had a VPN app installed called TunnelBear. Though it did not cause any problems in iOS7, in 8 it completly messed up the internet connection.

To solve the problem I needed to delete the profile TunnelBear created by going to Settings -> General -> Profiles.

It is possible that other apps \ profiles may cause more problems of this nature, so if you encounter anything like this — be sure to check your Profiles and VPN settings.

Hope this helps!