Monday 25 February 2013

iOS Data Synchronization - How???

I'm working on an iPhone app at the moment and I'm approaching the time when I'll need to do data synchronization with my backend Rails API. Up to this point, I've only pulled data down to the mobile device so the backend has acted as the sort of 'master' of the data. Now, data entered on the device will need to be incorporated into the 'master' data and available to all users.

I've sort of been deferring the decision of how to implement this until the last 'responsible' point because it's a daunting task... and done wrong, would perhaps need to be completely done over again in the future.

I remember the pain on my last project (an Android tablet app) after we brought in our first solution to data syncing between device and backend. We suffered through 3 months of headache and then gutted the whole thing for another strategy. The odd thing is the initial thing we'd gone for was one of the Android 'recommended approaches'. These things called Cursor Adapters. Steer clear! I'll maybe do a different post on these and why they are painful.

So, I'm cautious about using libraries intended to be a one-size-fits-all. Luckily I guess, I haven't actually found any for iOS, so I think I'll be rolling my strategy.

These are the questions I'm asking myself.

1. How close are the data models between the device and backend?
2. How much data will be need to be synchronized?
3. How frequently will it need to be synchronized?
4. If the user deletes the app and reinstalls it, will data need to be downloaded to the device in the same state as before the delete?
5. I'm going to need to know which data came from which user.. how will I tag the data as such?
6. How to queue up changes if they are made while the user if offline?

Because I don't have a huge amount of data that will need to be synched, my initial approach will be to set up a process that checks for changes across the tables where they might occur (initially only 2 for my case) and then pushes these to my RESTful backend using JSON over an HTTP post request. My backend, will then store these data in separate tables where the user and timestamps are recorded. After this, I should be able to set up another timed request. More posts as I move forward on this!

Tuesday 19 February 2013

My start-up experience (to date)

I've been working on GoFest, a start-up I created, for the last 4 months and it's been a really interesting ride. I'm close to an iOS app store release and I have my first potential customer. I realized I'd been blogging about the technical side of what I was doing.. but not on the experience itself. I wanted to remedy that! I think I'll keep trying to blog, but for starters, I want to give a little overview of how things have gone so far.

It all started when I left my job (of 6+ years) in software consulting last October. I did this for a couple of reasons.
  1. I was unhappy with the current state of things in my work life. I felt like things were in a rut and I wasn't growing. On top of that, there was a lot of conflict and aggression occurring in the project I was on that I was eager move beyond.
  2. I had a growing urge to start something on my own. I'd been exposed to the start-up world expanding around me and was getting more and more excited by it. I had a mobile app idea that I knew I could build, if I had the time.
  3. I felt starting a company would be a great opportunity for the growth and learning that I was craving.

So, off I went! I knew I would make a lot of mistakes, but I was hoping to make them quickly and learn quickly. I left my job and dove into learning how to start a company.

Here's a quick overview of the activities I busied myself with.

Reading
  • I knew I had a lot to learn, so I picked up 2 books that were recommendations from friends and collegues: The Lean Start-up by Eric Reis and The Personal MBA by Josh Kaufman. I've since read them both and they are invaluable! I'd highly recommend them to everyone working in the business world.
Market Research (This is where I started.)
  • I looked around for apps even remotely related to my idea. I compiled of list of those I felt would be competitors or those that should just be watched for future direction. I allowed this to influence my idea because it's likely better to create a product with as little competition as possible.
  • I explored the Twitter and Facebook world around the topic my app would relate to. People on these networks would probably be the easiest to reach later when I wanted to do user research.
  • I tried to define who my customer would be and what they were interested in/willing to pay for.
Business Model/Plan
  • This obviously has to make me money. How was it going to do this? When was it likely that this would first happen?
Define MVP (minimum viable product)
  • What was the minimum feature set I needed to get this to the market?
Building
  • I started building the product. It was a lot of fun! I hadn't done any iOS development before, so I had a lot to learn.. but it's fun learning a new language and framework. And you get all those little wins each time you make something work.
Outside Help
  • One of my weaknesses was that I didn't have a solid co-founder. I had an ex-colleague offering business type advise and I had a friend here or there helping with with UX (user experience) or design. 
  • Tandem Incubator - In early December I was almost 2 months into this whole thing and I decided to look into incubators. I'd heard of these, but had earlier felt that I needed to get a little further with my project before applying. I decided that now was the time and dove into the application process.
    • I worked very hard for about 2 weeks getting things ready for the application. Deploying the app's website, generating screenshots and even a presentation. In the end, I didn't get accepted. But, going through the application ended up being a really beneficial thing. I refined my business plan, answered some hard questions about timelines and really worked out what the 'Pitch' for this app would focus on.
Where I am I now?
  • My iOS is app is nearing completion (I hope to deploy it in the app store in the next 6 weeks)
  • I have my first customer (my app is sort of based on customer subscriptions in a way)
  • I'm running out of money. :-)
  • While revenue could start coming in soon, I'm realizing that it won't start pouring in any time in the near future.

So, I'm undecided on what to do! I'm still lacking the co-founder. I've been attending networking events with different entrepreneurial circles here in NYC. I'm seeking the cofounder at these, but I'm also seeking community and potential role models. This process has been really awesome actually! It's great to meet so many people doing amazing things. 

One thing that afflicts the developer entrepreneur is the knowing of the current state of the job market. There are lots of jobs out there for an experienced engineer. Exciting, well paying jobs! The lure of this is in the back of my head every time I think about my checking account balance.

I think blogging about this is good for me to figure out what's next. Maybe I'll get accepted to an incubator! Who knows? Maybe I do take a job with a start-up and learn in a more mature, but related environment.  For now, I'm going to keep plugging at it for a while more.

Thursday 14 February 2013

iOS provisioning HELL (solved)

Sometime I feel like the relationship I have with Apple is quite similar to that one would have with a bipolar boyfriend or girlfriend. The good times are really good... and the bad times are REALLY bad. But you just stay because you can't imagine life without them. :-) They brought us smart phones, mac books and iPods. You can't give those up! And they obviously brought us mobile apps easily distributed though an app store. This is great!

But it's well known that it's a pain the ass releasing your app through their long and tedious process. Provisioning used to be a nightmare! It also used to be hard to get your app to beta testers because you needed their phone's UDID and then you would have to produce a different build for each UDID. PAIN!

Test Flight was the earliest tool out there for managing your builds and distributing them to stakeholders, testers, etc.. I was even talking to Jeff Soto from the iOS Brooklyn Meetup and his team at Tendigi are building a tool to integrate Test Flight with their QA process. Very cool!

I've actually just started using AirOnApp because they go one step further and remove the need for collecting each of the UDIDs from every device that you'll distribute to during testing. They resign the app automagically for the each device. :-)

I'm planning on releasing my app in the next month and will use their automated release process as well. Hoping that goes as well as beta testing distribution!