Tuesday, December 20, 2011

MyLife Android

It was great partnering with MyLife to launch their Android application. Beyond the longstanding People Search of MyLife this contains a great way to see and post to all your social networks in one place. It makes "crossposting" and replying a breeze.

Or, if you like to see a tour, check out the YouTube video.

Wednesday, October 5, 2011

Dear Steve, we wouldn't have...

Dear Steve Jobs:

Thank you for being inspiring, innovative, and just an incredible person. Reading the blogs, news articles, and other press, we have to agree with all the positive statements about your life and contributions. Without those contributions, us and our family/friends:

  • Wouldn't have had this revived industry to create our startup mobile software company
  • Wouldn't have the ability to see to see loved ones realtime on business trips without a PC or Mac
  • Wouldn't have had that amazing feeling when the brand new box from Cupertino showed up at our doors (too often sometimes)
  • Wouldn't have realized that American ingenuity and passion can still mean something in the 21st century
  • Wouldn't have missed you as much as we do

Sincerely,

Lolay, Inc.

Thursday, September 15, 2011

App Upgrade Adoption

Here's an interesting adoption plot of active users on a particular version of a major social networking app on the iOS App Store (In this case it was a Universal App). What it's interesting to point out is two different upgrade scenarios.


One scenario (Dark Green to Mustard) is where adoption is organic through the App Store and relying on the app store itself to notify the user. The second scenario (Mustard to Blue) utilizes an alert dialogue to let the user know a newer version is available with a direct link to the download in the app store. Here's the comparison.
 iOS Organic AdoptioniOS Alert Adoption
25%2 Days2 Days
50%5 Days3 Days
80%12 Days6 Days
90%21Days 14 Days
95%23 Days15 Days

In a nutshell App Upgrade Adoption is slow, but you can certainly speed it up with an Alert when the user launches the app to let them know to upgrade to a new version.

Monday, September 5, 2011

Cowardly Lion

Ok, so I upgraded to Lion. Faster, better, smarter, right? Wrong. Trying to run a mobile development efforts for our organization has been a bit of an effort. As a background, I have a MB Pro i7 with 8GB of memory.

Here are the trouble pinpoints:
  • Crashes (Safari, Xcode, iCal, Mail and even the Preview app!)
  • Slow and laggy (Safari and Xcode)
  • CPU out of control. I've come back to my machine after 30 minutes to find 400% CPU utilization.
  • Finder/Icons gone. Sometimes during Xcode development, my icons disappear from the dock and I have no feedback as to which apps are running.

Here is what I've tried:
  • Clear Safari cache/history
  • Reset PRAM (http://support.apple.com/kb/ht1379)
  • Delete Library/Caches and ~/Library/Caches

So what worked?
  • Clearing Safari and my cache definitely improved internet performance.
  • Resetting the PRAM stopped my out of control processes (high CPU)
  • Deleting my caches seems to have stabilized the icons disappearing and some of the caches.

Will update this blog as I continue to be the Lion Guinea pig!



Thursday, August 18, 2011

What It Takes to Start Up...

This article is long overdue, but that in and of itself, should be an indication of what it takes to start something. My partner Gary Rudolph and I set out to change how/what our friends and family think about mobile about almost one year ago, and I really wanted to capture some of the thought process from beginning to end.

Intro:

There are plenty of articles out there that will try to teach you what it takes to start up a company. Please excuse any lack of instructions here as it's all from the heart. If you learn at least one thing new, or even question the current way you're running a startup, I consider this article a success.

The Phases:

There are many phases, as I would like to call them, that you need to go through for a startup. The number of phases is entirely dependent on starting capital and ability to execute. Each phase might be slightly different depending on the industry, experience, starting capital, etc. Our experience was fairly straightforward:

Phase 1: Be scared.

If I had to name the singlemost important skill, something that keeps everyone else from doing this crazy thing, it has to be courage. Or, the contra to that, would obviously be fear. Fear of no paycheck, fear of rock bottom, fear of the poor house, fear that my kids will starve. All of those need to go through your mind before you can move onto phase 2. If those ideas never popped into your mind, you aren't ready. Or worse... you're a VC. In either case, please stop reading. If you are a VC, jokes on us, please direct emails to love_funding (at) lolay (dot) com.

You need to have the courage to get past whatever it is that's stopping you, and jump off that proverbial entrepreneurial cliff so you can learn about yourself as a person. This phase is a lot easier when you have an awesome partner to go through it with you. By awesome I mean: Someone at your skill level or better, someone who is willing to put the same amount of time or more, and someone who can deal with your crap. That last part's critical, because it's very similar to a marriage; you get to keep half, and the kids [the idea] ultimately stay with one of you when you separate.

Phase 2: The idea.

Ok, so the idea was really there before Phase 1. I'm proud that you're catching on, but of course, there was some big idea that filled your empty time, that's what has gotten you through some tough days at work. However, prior to this moment, the idea was merely as a stretch goal. Something you could see yourself doing. It was never tempting enough to quit a job, or even take that less demanding job so you can really focus on the idea. This is the part where your addiction takes on a new shape.

The idea isn't the hero, you are. What do I mean by that? If you're stubborn and unwilling to see the idea morph and change based on needs, capital and demand, you're wasting your time. You sort of feel your idea taking over your every day thought process. When you speak with friends, you are only trying to learn more about how you can refine your idea so it has less holes. When you talk with family, all you can do is tell them about your idea...again.

Case and point: We started off with the idea of creating a social monetization platform that learns how consumers behave and helps them make the best choices depending on the time of day, previous tastes and ads they have really enjoyed (clicked on). Been there, done that (call us for more info). We soon realized it was the amount of time, energy and convincing (ourselves) we had put into this platform that made it important intellectual property.

It was incredible learning from it, but what we are doing now is 180 degrees different. Let's just say we are building the coolest mobile experiences for the greatest companies in Los Angeles. Being dynamic is critical to your livelihood and your sanity. If you are stubborn, you will fail. If you embrace change, it might make you a better person (as Gary puts it).

Phase 3: No sleep.

This is your time to shine. Can you look your wife in the eyes if you didn't give today 100%? In startup mode, you can't even look yourself in the mirror without giving 120%. We were working 100+ hours a week on slow weeks. My longest day ever was probably 24 hours straight of no sleep. I tried to sleep, but kept thinking of the big idea.

One major lesson learned: If the idea doesn't keep you awake at night, you either don't have a good idea or you don't believe in the idea. You better question your decision-making skills on Phase 1! Yah yah, you might have had a pushy partner that shoved you through phase 1, but why did you listen?

I remember having a meeting one morning at 9:30 AM in Malibu. We were typically working until 3 AM most days. Gary and I looked at eachother with our week-old beards and said: "Coffee?"

Mental note: Those are the fun days. After years of employment, management, analysis, and top-down pressure, we realized that creating is still the most attractive piece of this entire puzzle.

Phase 4: Go to market

Your baby is launched. It's live! You've made it, right? Think again. You need to acquire users, credibility, exposure and set your brand apart so journalists don't ask: "Oh, it's like that other app that does X, Y, Z?"

You will spend a lot of time following tweets, analyzing metrics and taking customer feedback. You will tweak your idea, refine, redeploy and have meetings to discuss the next iterations. You may even get lucky like we did and have some dough to spend on advertising. Great idea, let's blow thousands of dollars on banner ads each day... definitely lack of sleep.

Your family will likely stop answering your questions, and your wife will still completely support your intentions (oddly). All the meanwhile, the clock is ticking and you need to get past Beta so everyone in the world can enjoy your big idea.

Phase 5: Wait, we ran out of money? s*#@!

Oh no, the big idea took too much time to build. This happens, ALL THE TIME. The greatest ideas take time to execute correctly. It's all about your reaction and ultimate decision that will make or break you as an entrepreneur. In our case, we decided to bootstrap. We really believed, and still do, that we can run on lean cash flow and make something without the extra investment that would dilute our ownership. Every story is different, and I'm sure I can write an entire article on that decision alone.

Getting back to the topic at hand, what do bootstrappers do when they run low on capital investment (from their own checkbooks)? They help friends and colleagues achieve their goals for a little extra cash. We decided to commit some time to consulting so we could generate revenues that could be piped to our internal projects.

The decision was very simple: Take funding or consult and still retain 100% ownership. We decided we were very passionate about helping our colleagues in the same space, while also building our own confidence, and show that we can really kick ass when we aren't figuring out how to feed our families (Maslow's hierarchy of needs).

Phase 4.5: Getting back on track. Yes, this is phase 4.5, especially since phase 5 wasn't supposed to happen.

If you took investment money, you may pass go. Please don't read this next section as this phase is for the boostrapper-minded.

We got a little off track helping others succeed in the mobile game. I think the best way to illustrate this point would be through some Q&A:
  • Do we regret anything? No, we learned more than we expected.
  • Are we excited still? Yes, the market is still hot and ready for disruption.
  • What are we waiting for? Downtime, mostly. We spend 95% of our time on customer service and delivery.
Gary and I are entrepreneurs, no doubt about it. Since day one, we have sacrificed family, our significant others, kids, dogs, career path, finishing grad school, and many opportunities that would have been great learning experiences. We have battled house floods, Grave's disease, Gout, and created poor credit scores. I wouldn't change any of it for the world.

Addenda:

Someone asked me the other day: How do you know you've made it as an entrepreneur? Quite simply, the day you believe you've made it is when you stop being an entrepreneur. Keep running, improving, changing and creating...

Monday, July 25, 2011

2011 11" MacBook Air vs. 2011 15" MacBook Pro Xcode Performance

I just picked up the just released 2011 11" MacBook Air in the hopes of using that to replace my 2011 15" MacBook Pro. In the event it didn't perform well enough it would be given to the wife (actually, this was the original plan anyways, so if it can be a decent development machine, all the better)...

Here are the specs (Both with Lion and Xcode 4.2 and iOS 5 Beta 4).

  1. Decked out 2011 11" MacBook Air
    1. 1.8Ghz Core i7
    2. 256GB SSD (The faster Samsung one)
    3. 4GB Memory
  2. Decked out 2011 15" MacBook Pro
    1. 2.3GHz Core i7
    2. 400GB SSD (OWC w/SandForce, not OEM)
    3. 8GB Memory

For me the only thing that matters is Xcode performance. I just a project with the following characteristics, and measured a build from the time of pushing play to the time of the simulator launching with the login on the build displayed.

  1. 224 Source Files
  2. 63 XIB's
  3. 419 Resources
Here are the results:
  1. Clean Build
    1. MacBook Air: 38 seconds
    2. MacBook Pro: 16 seconds
  2. Repeat Build (No Clean, Simulator Left Running)
    1. MacBook Air: 8 seconds
    2. MacBook Pro: 8 seconds
It was expected the MacBook Pro would be faster. From a clean build it's significantly faster. From an existing build where you're touching a few files Xcode indexing to know what's changed or not makes it a wash. As most of the time we're just changing a couple files at a time the MacBook Air seems fast enough for development, just knowing that the clean build will take almost twice as long.

Also, to explain the difference, the actual copying of resources, launching the simulator, etc. took about the same time. There was a moderate difference in the compilation time, but the static analysis is where the MacBook Air lost out. The MacBook Pro killed it with the extra two cores and processor speed.

Now, the debate... I think I'm going to try out the MacBook Air and see how it goes...

UPDATE: After using the MacBook Air I decided to stick with the MacBook Pro. That extra speed really matters when someone is looking over your shoulder. Particularly, at a client. Although, if you are used to a non-SSD MacBook Pro (particularly, the 2010 variety) you'll be happy with the performance of the Air.

Thursday, July 21, 2011

OSX Lion and Xcode 4.1

We've upgraded to OSX Lion and Xcode 4.1 and it has been an interesting process. Here's the steps we took.
  1. The first was to make sure we were upgraded to 10.6.8 before we started anything.
  2. Purchase and download OSX Lion from the App Store (Note, you before starting the installation you may want to create a bootable drive)
  3. Install OSX Lion
  4. Java is not installed by default, so after Lion is installed you can install Java by going to a Terminal and typing "java -version" and it'll start a download to install Java.
  5. Before installing Xcode 4.1 it's good to remove any previous versions of Xcode
    1. Uninstall any previous Xcode by issuing a "sudo /Developer/Library/uninstall-devtools"
    2. In ~/Library issue a "find . -name *Xcode*" and remove each file/directory
    3. In ~/Library issue a "find . -name *Simulator*" and remove each file/directory
    4. Reboot
  6. Next find Xcode 4.1 on the App Store and download and install it. This just installs the installer. You then have to install it. The installer can be removed when you're finished.
  7. If Xcode launches with errors or has no menu times you'll need to reinstall iTunes. The download has the 64-bit universal builds now.
The only issue we've seen is that Core Location isn't working in the simulator and generates an error. See our post on the developer forums.

Monday, June 13, 2011

Reading and Translating a DWARF'd iOS Crash Dump

So what the heck does it mean when a crash log has the following lines?
Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x35167c98 0x35165000 + 11416
1 CoreFoundation 0x315b1cd6 0x315b0000 + 7382
2 CoreFoundation 0x316620b8 0x315b0000 + 729272
3 CoreFoundation 0x31663438 0x315b0000 + 734264
4 CoreFoundation 0x315b9f98 0x315b0000 + 40856
5 CoreFoundation 0x315c094e 0x315b0000 + 67918
6 Foundation 0x34e9831a 0x34e81000 + 95002
Chances are, your Released application has Debug symbols stripped (DWARF), but have no fear, the Developer tools come with the right script to help with this. It's called symbolicatecrash, and with Xcode 4+ it gets installed to:

/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash

I've simply create an alias in my bash resource on login, but you may prefer a symbolic link. Hopefully you've kept a copy of the build when it was released, because the dYSM file contains the right mojo to add the symbols back. The following sample translates the often cryptic lines of a .crash file into something more understandable:
symbolicatecrash MyOopsAppWithABadBug.crash MyOopsAppWithABadBug.app.dSYM
The options are more clearly defined by adding the -h switch:
symbolicatecrash  -h
usage:
/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/
Versions/A/Resources/symbolicatecrash [-Ah] [-o
] LOGFILE [SYMBOL_PATH ...]

Symbolicates a crashdump LOGFILE which may be "-" to refer to stdin. By default,
all heuristics will be employed in an attempt to symbolicate all addresses.
Additional symbol files can be found under specified directories.

Options:

-A Only symbolicate the application, not libraries
-o If specified, the symbolicated log will be written to OUTPUT_FILE (defaults to stdout)
-h Display this message
-v Verbose
Abracadabra! Those lines are easier to read now, but we have some work left to find the double-release or message sent to an object that is already evicted:
Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x34499c98 objc_msgSend + 16
1 CoreFoundation 0x308e3cd6 CFRetain + 62
2 CoreFoundation 0x309940b8 __CFBasicHashStandardRetainValue + 8
3 CoreFoundation 0x30995438 __CFBasicHashAddValue + 100
4 CoreFoundation 0x308ebf98 CFDictionarySetValue + 68
5 CoreFoundation 0x308f294e -[__NSCFDictionary setObject:forKey:] + 54
6 Foundation 0x341ca31a -[NSMutableDictionary(NSKeyValueCoding)setValue:forKey:] + 10
You can read more about the Debug and Symbolification process here: http://developer.apple.com/tools/xcode/symbolizingcrashdumps.html

Friday, April 29, 2011

Zbar on Android with the NDK

We've had experience writing an automobile VIN (Code 39) scanner on both iPhone and Android. In the case of the iPhone we leverage the ZBar library and the Android the ZXing library. Unfortunately, Android has been a tremendous amount of work. There was a tremendous amount of fracturing with the camera drivers to code around to tune the image capture. But that's another story...

For the image processing the ZXing library on Android with was simply not as fast or accurate as capturing   Code 39 barcodes (no opinion on QR, etc.) as ZBar on the iPhone. This left an interesting customer service dilemma as Android would be subpar. We looked at a few options and settled on an interesting proposition.

Android recently introduced the NDK (Native Development Kit) that allows you to build native code from C/C++. Interesting... We realized that there was a good chance that we could get the ZBar library running on Android with the NDK (at least for the image processing). We did have to rewrite the build/make system as the NDK does not have full make/configure support. But, after investing time in this we were able to build the ZBar library on the NDK and leverage their JNI wrapper to invoke this code on Android.

So far the results have been excellent. The ZBar library on Android is 50% faster in recognition for Code 39 and a lot more accurate.

We'll be donating an example project to the ZBar project once we can remove the client specific portions.

Also, just be aware this only applies for Code 39. We have no idea how the image processing quality compares for the other formats.

Saturday, April 9, 2011

How to Upgrade Test in the iOS Simulator

For the purpose of upgrade testing in automation it's useful to have a build of the previous version of the application. Of course, for actual device installs this is easy with the use of adhoc builds and .ipa files, but for the Simulator this is a little more involved. It is feasible if you follow the following steps.
  1. Launch the Simulator (/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone Simulator.app) and set the hardware and version to the appropriate settings.
  2. Delete any existing apps in the simulator.
  3. Put a breakpoint in the main function (i.e. first line of the main function main.m). This is to ensure that no code writes any files to the build directory (i.e. CoreData, Analytics, Preloading URL's, etc.).
  4. Run the project in debug and stop the program once it reaches the breakpoint in the main function.
  5. At this point if you followed step (2) and only have one application it should be easy to locate in ~/Library/Application Support/iPhone Simulator/[version]/Applications and can easily be tar'ed up and archived and moved around.
Now in an automated testing script you can remove any applications from the simulator, untar the appropriate archive, exercise preloading (i.e. logging in) to get the simulator in a state to test an upgrade. Now, simply build the project and have it install over this version and test any upgrade scenarios.

This has even worked from Xcode 3.2.6 builds being applied to Xcode 4.0.1.

Tuesday, April 5, 2011

iPhone Open Source Automation

Testing iPhone apps is always thought of last and is typically performed manually. At Lolay we believe in a strong automation investment to allow testing as we develop so that we can have confidence in the stability of our builds as we develop.

Checkout a demonstration of how to automate the iOS platform / iPhone using all open source. This is all compatible with ANT and Maven in any continuous environment. In this demo you will be shown on open source can perform a basic test in Where U At? and run through both positive and negative testing. At the end you can see the JUnit results including screen shots of the failure.

Vimeo: How to automate the iPhone using open source

Wednesday, March 9, 2011

BIA/Kelsey Reviews Lolay, Future of Things to Come

Gary recently spoke with Mike Boland from BIA/Kelsey about Lolay's social and location-based efforts. You can read the details here.



We are excited to note several key areas where Lolay will be focusing its efforts:
  • Where U At? iOS: Where U At? for iOS will have some major updates within the next two weeks. Look out for the details!
  • Where U At? Android: We have been working diligently to release Where U At? for Android and are pleased to announce it will be in the Marketplace very soon!
  • Lolay's Incubator: Helping other developers (novice to experienced) create apps that make money and solve a problem out of the starting gate. Our Lab Werx platform will serve as the foundation for quick success.
  • Partnerships: We are looking for like-minded people, companies and mobile efforts that are complimentary to Lolay's mission to change the way people interact. Feel free to Connect with Us.
Looking forward to a great 2011!

Saturday, January 29, 2011

Mobile, Token Based Authentication

We've had some recent discussion on mobile authentication and thought it might be a good time to discuss how this works in the Where U At? application where we had white space to start fresh. For the most part we took a lot of insight from Twitter to use a token based authentication method, but not use OAuth. It's more of a service based OAuth that fits better in a paradigm where applications will interact as a service and want to tightly control the authentication service.

As everything in Where U At? it's a REST implementation that looks like the following (a few details are omitted):

  1. POST: /tokens
    1. Request Data
      1. email
      2. password
      3. manufacturerId
    2. Returns: Token
  2. GET: /tokens/{UUID}
    1. Returns: Token
  3. DELETE: /tokens/{UUID}
Behind the scenes we have a few objects that make this all work on the server.
  1. Token
    1. token_id
    2. expiration
    3. user_id
    4. device_id
  2. User
    1. user_id
    2. email
    3. name
    4. password (one way encrypted)
  3. Device
    1. device_id
    2. type
    3. manufacturer_id
    4. security_id
Any application can create a token (i.e. login) and store the token or token_id locally and reuse that. For any requests to our other services you simply pass an X-Token header with the token_id as the value. The other resources will validate the token is valid (i.e. that it exists and is not expired).

Any application can verify the token using a GET request if they so desire. Additionally, they can delete a token to perform a logout.

We follow a practice that only one user and one device can have a token active at any time. This means that if I login into my iPhone and then my iPad the token for the iPhone is deleted on the server. This works for us in a Location Based Application with push notifications to ensure only one device for a user is updating location at a time. It also ensures push notifications go to the right device.

A token_id has the same security behavior as a cookie based session id like every web app in existance these days and can be "stolen". To prevent this all requests are encrypted using standard SSL (not just login) so that only the server and device ever can see the token.

Where U At? Server Release 8 (1/29/2011)

Another month in the new year almost over and another release from team Where U At?! Another quick server release to upgrade to the new CityGrid v2 API's. With the new CityGrid v2 Offers API we are considering another upcoming release to make our deals/offers better!

Where U At? Server Release 8 (1/29/2011)
  1. CityGrid v2 API's which has made our app faster for finding places and locations!
What are you waiting for? Download the FREE app from http://bit.ly/whereuat

Monday, January 3, 2011

Where U At? Server Release 7 (1/3/2011)

Happy New Year from the Where U At? Team! We have a quick release in the new year to fix a few bugs.

Where U At? Server Release 7 (1/3/2011)

  1. Made the push notification text more clear when accepting a meetup
  2. Location access for a Friend was showing as Disabled even when you requested All The Time
Again, if you *still* haven't download our FREE app yet, you can download it from http://bit.ly/whereuat