touchlabblog

[touchlabblog]

March 2014 Android Meetup - Android and Design

You know it's going to be a great meetup when the pizza runs out before the talks even start. On Wednesday night we hosted our “Android and Design” meetup at Tumblr and had a huge turnout of about 200 members. We were treated to exceptional pizza (the sausage one was bangin'), Budweiser (Tumblr's “favorite”) and a cozy space with many picturesque picnic tables.

Touch Lab president and meetup organizer Kevin Galligan started the night off with announcements. Space Apps, which Touch Lab is sponsoring, will be happening April 20-21 in New York City. It's a tech development/problem solving event that takes place in over 75 cities worldwide.

We also announced DroidconNYC. Droidcon is the largest international Android convention spanning 15 cities and counting, consisting of barcamp, hackathon and conference/workshops. Droidcon's main flagships are Berlin and London, and the team here at Touch Lab will be organizing DroidconNYC, the first one in the USA! We're looking for volunteers, sponsors, venue suggestions and contacts. If you're interested in supporting Space Apps and/or DroidconNYC, get in touch with us.

Kevin also talked about app demos. If you have an app that you'd like to demo at our next meetup, get in touch with us. We'll install your app on our device and at the end of the meetup, you'll have two minutes to demo your app to everyone. Our host at Tumblr, Chris Haseman, then gave a warm welcome to the crowd and talked about their awesome Android team (hint: they're hiring).

Dave Redding and Walter Dziemianczyk, our very own developers at Touch Lab, started the talks off with their topic, hidden patterns in Android. They gave overviews on Gaussian blur, pull to refresh and Google+ share and how they're UI/UX features that aren't in design docs but are widely used. Their talk is here.  

Kevin Grant, Android engineer at Tumblr, gave his comedic take on Android design and ways to rethink how you approach design. His talk is here. Don't you love it when your designer asks, “How hard would it be to do this?” His motto? “Say yes!”

Deniz Veli and Paul Lau then delivered a detailed talk about end-to-end Android design at Etsy. Paul showed slides of screen sizes that he designs for, and also sample markups to demonstrate how devs and designers collaborate at Etsy. Their talk is here. After Q&A and great design insight from our speakers, we mixed and mingled and moved the party to Lillie's for drinks and more conversation.

Join us next month at StackExchange for Mark Murphy's talk. We'd like to give preference to Android developers since this will fill up fast, so please get in touch with me and clarify that you're a dev if you'd like to be added!

See you next month,

Olivia

Operations, Touch Lab

Co-organizer, NY Android Developers Meetup

[touchlabblog]

February 2014 Android Meetup – Android and Devices

A very wise developer once said, “Coding is fun, but sandwiches are better.” Thanks to Google and our amazing speakers at our "Android and Devices" meetup Wednesday, we had bits of both. Early birds started arriving around 6pm and helped themselves to an impressive array of sandwiches, soda, chips and brownies.

While everyone mingled, I went around with Mike, who graciously helped me give out raffle tickets for two Spheros, robotic gaming balls that you connect and control with your phone or tablet. To kick off the meetup, Kevin welcomed the group with a warm (and as usual, comedic) intro. For our avid tweeters, he shared our new meetup Twitter account, @NYAndroidMeetup and our hashtag #androidnyc. He also introduced me! If you have questions or suggestions about meetup logistics, please let me know - we're always looking for people to present and new topics.

David Haddad, Founder/CEO of Open mHealth was our first speaker and talked about why open software architecture is needed to make sense of the array of data coming from health apps and devices. He showed a real-life example of a patient who had post-traumatic stress disorder. A health app showed his decreased texting activity to his wife and helped doctors realize that he was becoming more distant as a result of PTSD.

  Inder Singh, Founder/CEO of Kinsa Health demonstrated the Kinsa thermometer on an Android device with his marketing guru Erin Koehler. They aim to map the spread of diseases in real-time with their smart thermometer, while keeping it fun and comfortable for kids. Inder also discussed the pros of working with Android, such as being able to use the audio jack for input/out simultaneously - something you can't do on iOS.

  Izzy Johnston, Lead Android Developer at Quirky bravely took the stage without a PowerPoint presentation, but she didn't need it! She talked about Quirky's mission to bring new inventions into the market through voting from their online community and their own product design team. She also connected her Pebble watch via bluetooth and switched on a lightbulb nearby!

Last but not least, Dario Laverde, Developer Evangelist, gave his intro talk about working with the Glass API and what's in store. He also showed the array of functions that Glass is capable of, including "read my mind" and "play a game."

Our curious audience had many questions about the various devices after - I'm glad our presentations didn't run over so we had time for all of them! Izzy then helped us select two lucky winners of the Spheros. Before the night ended, we wanted to try a new thing we learned from Larry Legend from the NY iOS Developer meetup. We gave developers a chance to talk about any open source projects they're working on, connect with job leads, etc. Kevin then thanked everyone for coming, and a few energetic meetup attendees joined our Touch Lab team for drinks at 675 bar afterwards.

  Thanks to Roman at Google for coordinating, and to our speakers! Save the dates for our upcoming meetups:

March 12 at Tumblr - The topic is Design

April 16 at StackExchange with Mark Murphy, who will talk about the next billion Android users

    See you in March,

Olivia

Operations, Touch Lab

Co-organizer, NY Android Developers Meetup

[touchlabblog]

January 2014 Android Meetup - New Year's Resolutions

New years resolutions... a fad that's gone by February or one that will stick around? Hopefully it's the latter for the 100+ attendees who came out for our New Years resolutions meetup on Wednesday! To ring in 2014 the right way, we wanted to talk about things that we should be doing, but don't. As our meetup's founder and Touch Lab President Kevin said, it's time to make some resolutions (or at least watch people talk about them). 

Our gracious hosts at The New York Times kicked off the meetup with a warm welcome from Kate, their mobile product manager, and Howard, their lead developer. After Kevin's housekeeping announcements, talks started with Paul Dupuy up first; he showed everyone how his product Duologue helps you compare app screenshots with mockups, track bugs and comment. Kevin spoke about IDE's (Integrated Development Environments), especially Android Studio, and Kevin Schultz from Lua Technologies talked about more advanced Gradle features. Dave Redding and Matt Davis, developers at Touch Lab, spoke about using Robotium vs. Espresso. The night ended with questions from the audience and more mingling. 

Thanks to The New York Times for their hard work and the amazing space, and to our speakers! As for upcoming meetups, here's 3, save the dates:

February 12 at Google (connected devices including Glass) 

March 12 at Tumblr (design)

April 16 at StackExchange with Mark Murphy, who will talk about the next billion Android users.

Until next time!

Olivia

Operations, Touch Lab

Co-organizer, NY Android Developers Meetup

If you're not subscribed to our meetup announcements, make sure you turn them on here.

[touchlabblog]

Our very own Dave Redding speaking at the University of Scranton

At Touch Lab we're not shy about telling everyone how amazing our team is and we just love it when other organizations recognize how great our people are. Today (November 19th, 2013) Dave Redding, one of our Senior Android Developers, is speaking to the Association for Computing Machinery at his alma mater, the University of Scranton about his ongoing experience with startups, programming and mobile in NYC.

We pulled Dave away from his screen for a few minutes to find out a little more about this talk.

So how'd you end up with this speaking gig?

My buddy Joe still works at the university and the professor in charge of ACM was looking for presenters. Joe suggested me and the professor remembered me and reached out (Dave did his undergrad and grad work there and even taught Computer Literacy for two years).

Can you give us a few highlights from the talk?

I'm going to talk to them about my journey from university to now. My first job was as the lead Android Developer building the USPS app in a big organization. After that experience I realized that I had ambitions of greater things and found Touch Lab on Stack Overflow. They were a smaller, tight knit firm where I wouldn't get lost in the clutter. I wanted to be a better programmer, this was the place to do that.

What do you hope the students are going to get from it? That programming for Android doesn't have to be difficult if you know what you're doing. There are ways to solve the big problems and you can reach out to the open source community for help with those like syncing, fragmentation, user experience.

Give one piece of advice to today's undergrads that you wish you knew back then. Be more active in the open source community. As an undergrad I didn't feel I was qualified and I was scared to jump in. The world is not filled with bad people, people are wiling to help you if you just expose yourself a little bit.

[touchlabblog]

Hacking the NY Android Developers Meetup

On the Touch Lab blog last week we shared that the New York Android Developers Meetup is getting to be too much for awesome Kevin to handle alone, and that we're looking for a (paid) Part Time Event Coordinator to help make the meetup bigger and badder than ever. While we can't wait to get the right person on board and let them loose, there's another equally important thing to consider. What does the community want to see happen with the Android Developers Meetup? At last night's meetup we had two great presentations on a collection of image download/cache tools, one by our very own Dave Redding and the other by Matt Spitz. After the demos we took advantage of the fact that we had some of the smartest minds in New York in the room and we hacked the meetup.

With just a few minutes of brainstorming with the community we came up with a few dozen ideas, some good and some great. Even while we're looking for the Event Coordinator to take the meetup to the next level, we're going to start filtering through the ideas the community generated and find ways to implement some of them.

If you missed it, here's a random sampling of some fun ones:

Open source community projects and solving day to day problems that Android developers struggle with

Ping Pong Tournament at a Beer Garden with prizes

Google Glass Hackathon

Building an Android game show with mobile devices and tablets

What's new in KitKat?

Bacon?

Discovering new UI patterns

In app marketing and how to monetize apps

What are your ideas? We'd love to hear your feedback on how to make NY's best Android Meetup even better.

——————————————————————

Are you one of the best Android developers out there who likes solving problems, working on a small, agile team and building only the best solutions? Maybe we should talk, get in touch.

——————————————————————

Looking for a great team of focused Android experts to bring your idea to life? We do one thing: make Android apps. Keeping that focus means we can do things the right way. Let’s chat about your project, get in touch.

[touchlabblog]

8 tips for building a badass offline app

This is Part 3 of 3 in a series on Offline Connectivity. Read Part 1: No Connection? Big Problem Read Part 2: Offline functionality is a no brainer (and how Twitter dropped the ball) ------------------------------------------------------------------------

Most developers hone their coding skills by learning how to build web apps. On the web, you’re always connected: you can submit data instantly and check out recent changes with a simple refresh. And if something goes horribly wrong, your user will be able to detect it right away.

Not so with mobile.

Despite the fact that it’s impossible for mobile apps to be constantly connected to the Internet, many developers design them as if they will be. Even when building in valuable offline support would be easy, dev teams often don’t even think about it.

Here are eight tips for building a smart mobile app:

1. Assume your app will usually be offline

For your app to be the best it can be, the wise thing to do is is build it with the assumption that it will be offline most of the time.

Think about it: just because your phone thinks its online, does that mean your request will succeed? What if your device is connected to WiFi, but the router isn’t? What if your server is down? What if you’re in that strange netherworld where the phone thinks its online, but you just got in the elevator (ie “softline”)? Etc.

Lots of things can go wrong. It’s better to think like you’re always offline, with an occasional chance to talk to your server. Stop talking about offline “mode.”

2. Work smart

Does your entire app need to work offline? Probably not. Make a list of all features and estimate a) how important that feature is, and b) how hard it’ll be to support it offline. To maximize your efficiency, pick the good stuff and skip the rest.

3. Do the bare minimum

If you want your app to keep user adds/edits (and you should!), but you don’t want to implement a full db table sync, you can simply push the add/edit command into the queue and let it process later when there’s a connection.

Basically, the json you were going to send to the server gets stored in the command before it can be sent. The benefit is that the user won’t lose data entered offline, and you’ll keep your logic to a minimum (full 2-way sync is significantly harder than 1-way, in either direction). It’s a bit “ugly,” but will keep the users happy. Its also a lot cheaper to implement.

4. Choose an offline sync method

There are two basic methods of syncing: state-based (SB), and command-based (CB). (For a really detailed explanation, check out our post on Data Synchronization.)

SB and CB are conceptually the same, except that SB requires you to recreate the list of commands yourself from the “state” of the data, while with CB, you explicitly record the commands as you go. CB also lets you do stuff that isn’t in the DB, like upload images.

SB queries the database to see what needs to be synced. This generally manifests as a “dirty” flag on the table in the form of an “updated” timestamp. The concept is simple, but the process can become a huge pain as your DB gets more complex. Especially with foreign key relations.

CB, on the other hand, has these operations explicitly added to it from your app. If you save an account entry, for example, the command to send it to the server is recorded in the CB queue. This means they’ll run the moment your app detects a friendly network condition. CB’s complexity grows more linearly with DB complexity than SB. (Touch Lab wrote a CB command queue called Superbus --I recommend you try it! There’s a simplified v2 in the works.)

5. Understand the difference between temporary and permanent issues

Unlike most web app errors, mobile “headless syncing” errors aren’t immediately apparent to the user, which means they might not get fixed.

This means it’s critical to understand the difference between temporary and permanent issues. Temporary issues usually spring from having no internet connection, or a down server. (In Android, you also *maybe* have to worry about the SD card being removed.)

Pretty much everything else is a permanent issue, and your app needs to be equipped to deal with them. At a minimum, build in messages that will tell your user what’s up when something goes wrong. You can also give them a chance to resubmit. Whatever you do, don’t just “drop” the command. Nothing gets your app a 1 star review faster than losing your user’s precious data!

I’ve noticed that new developers tend to lean towards assuming an issue is temporary, but this is dangerous. (Read the Superbus docs.) If you’re not careful, you can wedge your app permanently, as the queue will try your command, “fail” temporarily, and shut down to wait for more favorable conditions -- which will never come.

That, of course, assumes you’re using our queue process, or something similar. Even if you roll your own, though, think about it. You have to be VERY careful with error handling. What happens when there’s an error? Do you skip the update? Can you? Was it really a problem, or was the server down?

One example from Touch Lab: we implemented an app with the first version of the queue, interpreting all IOException instances as network issues. This, of course, was wrong. There ended up being an image upload command that was trying to send an image that had been deleted.

(Whoops. Life would be much easier if there was ShittyNetworkException, but there isn’t.)

Additionally, some server APIs use http codes well, but many will return 200 regardless of what happened and push actual error conditions into custom fields. This makes identifying errors more difficult -- you may “finish” the command when you really had a data problem.

6. Don’t wedge your app

This applies directly to people using the Superbus queue, but in theory it goes for everybody.

You need to discern what exceptions are temporary in nature from permanent, and you need to keep temporary sync events in a “pending” state. In CB, that means leaving them in the queue. In SB, that means leaving your “dirty” flag dirty.

Also, unless you have a really loose schema, you need to process things is some form of temporal order, or everybody will get upset (either your users, because something from five days ago just came in, or your data, because of foreign keys).

The big danger here is wedging your app. Permanently. If you keep thinking an exception is temporary, when its really something that’ll never go away, you’ll leave the app in a never ending state of incomplete sync. Nothing that comes after the poison event will ever process.

In Superbus, there’s a CommandPurgePolicy that you can implement to force something out of the queue. If something has been processing for a while, you can dump it. Sounds nice, but this is MUCH harder to do well than you think. How long before you dump it? Under what conditions? Also, nothing else processes while this is being decided.

The default policy in Superbus is TransientMethuselahCommandPurgePolicy -- because I like funny class names, and I want to make sure you understand that if you don’t do this properly, the command will live forever.

7. Opt for multiple ID values

If you’re a sane person, you use numeric IDs on your tables. When I first started doing sync on mobile, I tried to keep one “id.” Like a concerned parent, all I can say is: don’t do this. You’ll regret it later. For two-way sync entities, have a “localId” and a “serverId.” It’s just a lot easier to manage. (Say you create a value, then go back in to edit it while your sync is processing. You’ll either crash or create a duplicate entity.)

8. Understand data storage vs Id storage

When you add/edit an entity, and create a command to push the data, you can either keep a reference to its local id, or create a json dump. There are arguments for each -- and to be totally honest, I flip flop periodically.

Keeping the actual data means you can send things in their actual order. If you only push half of the commands before losing your connection, a remote client should have a reasonably coherent version of the “truth” because the remote data was added in order. You can also do update “slices,” which only update certain fields, rather than whole entities, which is very valuable if multiple users are making edits.

Id references, on the other hand, are generally easier to implement if it’s not super critical to have your updates process in order. You can “collapse” them, so multiple edits are contained in one “command.” And if you upgrade your db schema, the data in the app queue isn’t “stale.”

However -- and this is critically important -- if you’re using id storage and your tables reference each other, give your “create” commands a higher priority. This makes for a bit of a temporal issue, as it’ll run all of your creates before your updates -- but if you run an update and set a foreign reference to an entity that doesn’t exist yet, you’ll be having a bad day. You can mostly avoid this problem by slotting all of your adds first, although there are times when that won’t work right in all cases. Think defensively about how things will process in the real world.

Coming Soon, Touch Lab's First eBook!!

——————————————————————

Looking for a great team of focused Android experts to bring your idea to life? We do one thing: make Android apps. Keeping that focus means we can do things the right way. Let’s chat about your project, get in touch.

——————————————————————

Are you one of the best Android developers out there who likes solving problems, working on a small, agile team and building only the best solutions? Maybe we should talk, get in touch.

[touchlabblog]

Offline functionality is a no brainer (and how Twitter dropped the ball)

This is Part 2 of 3 in a series on Offline Connectivity. Read Part 1: No Connection? Big Problem Read Part 3:8 Tips For Building a Badass Offline App ------------------------------------------------------------------------

As a startup founder, I get it: it’s a lot easier to compete in an existing market than one that doesn’t yet exist.

But as a developer, my goal is to build apps with the highest level of functionality possible.

In Touch Lab’s grand vision for the future, android users will be able to interact fully with their favorite apps whether or not they’re connected to the Internet (except for features that specifically require a connection).

Twitter: just … why?

Twitter’s Android app is a prime example of what can go wrong when developers turn a blind eye to offline functionality. If your tweet doesn’t publish (say, because of a failed Internet connection), it automatically gets filed into a “drafts” folder. Where it goes to die, basically.

In addition to users being notified only once about their failed tweet, navigating to the “drafts” folder is like finding a needle in a haystack -- a haystack positioned at the end of a 10-mile maze. From a developer standpoint, it’s really, really easy to program the app so that the tweet is automatically queued up when a connection returns, so I have no idea why Twitter doesn’t do this -- it's incredibly frustrating from a user’s perspective.

Take this example and multiply it by a bajillion, and you have the general sorry state of Android apps today.

UX to the rescue

Fortunately, the UX (user experience) community has done a great job recently of convincing people that the user’s perspective is actually important.  A few years ago, UX was new and mysterious, but now companies, from Apple to hot new startups, pour big bucks into it because they understand that users respond to -- and eventually adopt -- apps and platforms that just work.

Although we generally think of UX as the practice of “figuring out where the buttons go,” the manner in which your app behaves in adverse conditions will increasingly be a part of the overall experience the farther we move away from the desk.

Very often, developers frame the offline debate as a black and white issue. It’s either “we support offline,” or “we don’t, because it would take a massive rewrite.” The reality, however, lies somewhere in the middle.

  ——————————————————————

Looking for a great team of focused Android experts to bring your idea to life? We do one thing: make Android apps. Keeping that focus means we can do things the right way. Let’s chat about your project, get in touch.

——————————————————————

Are you one of the best Android developers out there who likes solving problems, working on a small, agile team and building only the best solutions? Maybe we should talk, get in touch.

[touchlabblog]

We're Hiring a Part-time Event Coordinator!

As an Android-only dev shop, Touch Lab is proud that our founder Kevin runs the number one Android get-together in New York. With 1200+ incredible members and 26 awesome events behind us, the monthly New York Android Developers Meetup is the place where the best Android developers in the New York Tech scene (and their fans) come together.

With your help, we’re looking to make it even bigger and badder. We're looking for a smart, friendly, and organized leader type who is passionate about New York’s tech scene and interested in event planning and business development to take the helm, manage the event and help us continue to improve the meetup.

3 reasons we're hiring:

The meetup is amazing, and with all the growth Touch Lab is experiencing, Kevin can't always give the meetup the time it needs

The Android community is amazing, and we feel a responsibility to invest in making the meetup the best it can be

Our sponsors are amazing, and they want to offer value to the community; we want to help them do that in the best possible ways

There's a top-secret fourth one (it's at the bottom)

Here's the basics of what we're looking for:

You're an recent grad or career-changer and want to get your foot in the door of the New York Tech scene, but you're not a developer and haven't yet launched your first world-changing startup.

You're organized. No seriously, you're crazy organized and you really love the whole "being organized" way of life.

When you go to a meetup or a conference, you look around and think things like "why didn't they get xyz company to sponsor, they would've been great?" and "wow, a little extra effort and they could've made this way more awesome by doing xyz"

Sound interesting? Read the details below and then get in touch with us. By the way, it never hurts to be introduced by someone who's a mutual friend.

The Gig:

Paid (as in not an un-paid internship).

Perfect for a recent grad or career changer who is passionate about New York’s tech scene and interested in business development, event planning, and community management.

To start, we’ll need you for 5 to 10 hours per week, and up to 20 the week before the meetup.

For the most part, where and when you work will be up to you.

The Responsibilities:

Booking some of the biggest names in the Android scene (past speakers include Chris Haseman of Tumblr and Google’s Roman Nurik)

Planning and executing meetup logistics (from securing space to ordering food)

Dreaming up exciting spin-off events based on the NYC Android community’s needs

MC-ing each meetup

Collaborating with existing sponsors to arrange prizes and promotions (previous sponsors include Google, HTC, New Work City, and Amplify)

Leveraging Touch Lab’s connections to form relationships with new sponsors

Managing the Meetup page and communicating with members

Collaborating with Touch Lab’s agency NoFancyName to develop promotion strategies

Sound good? We’d love to hear from you! Please email us, briefly tell us a little something about yourself (LinkedIn profile, blog links, previous events you've run, favorite whiskey, things like that) and give us a few sentences about why you’re interested in the NY tech scene and this gig in particular.

——————————- Shh...the top secret fourth reason. Keep this between you and me, but with the growth at Touch Lab, we're going to be hiring a BizDev type who knows the community well sometime in 2014. We'd definitely consider someone who'd worked with us as say, a part-time event coordinator, to be a very strong candidate.

[touchlabblog]

Collaborate with Touch Lab and get a job at a great NYC startup

Over the next few months we're rolling out a program that we're really excited about. Select clients will be able to embed a developer with our team for the duration of their app build (and maybe beyond). They will work side by side with our team, learn, train and share knowledge with us. The client not only gets a great app, they also get a top-tier internal Android developer who's had chance to level up their skills.

Our first group consist of developers from two of our awesome clients: TheLadders and Cover. In fact (as you might have guessed from the title), our friends at Cover are using this as a really clever recruiting tool; so if you're a kick-ass Android developer and you want to work for a great startup (and collaborate with us), check out the post and get in touch with them right away.

---------------------

Our Embedded with Touch Lab program is not yet officially launched, but we will respond to all of you who've been emailing about it. Feel free to continue emailing us about it, just please understand that it may be a couple of months before we can offer a spot for your developer to apply for.

[touchlabblog]

Thank You for the Feedback on the 1 Second Everyday App Release

We have great clients and push to create the best possible Android apps for them, so on release day we always feel good about the product we're putting into the world. That said there's few things better than to hear that others also love what we've put together.

Thank you to everyone who's downloaded the 1 Second Everyday app so far, and a special thanks to everyone who's taken time out to rate the app, it means a lot to us and to Cesar & his team.

In addition to the users letting us know they love the app, we're excited and grateful to get great feedback from all around the internet. Thank you for your reviews and mentions and we'll be sure to add any additional pieces as they're posted.

Matt Cutts: Gadgets, Google, and SEO

Android Police

Jamie & Adam - Tested

Droid Life

Tutto Android

[touchlabblog]

Bringing An Awesome App to Life: 1 Second Everyday for Android

One of the coolest parts of being a mobile developer is getting the opportunity to build apps you’re excited to use yourself, which is why I’m thrilled to announce today’s launch of 1 Second Everyday’s Android app.

I’ve been a fan of 1SE since last year, when I watched creator Cesar Kuriyama’s popular TED talk. At 30, Cesar started recording one second of each day of his life so he would remember something about every single number on the calendar (and motivate himself to live a life worth capturing).

Check out this compilation of his 30th year here: 

Touch Lab’s app makes it easy for users to conjure up the same magic: they can record video of their day’s pivotal moment, and then edit it to isolate the exact second they want to capture. When they want to look back on their experiences, users can view compilations of the selected seconds in any increment of time they choose, from one month to one decade.

Completing 1 Second Everyday’s app took more time than expected -- not to mention a serious dose of  blood, sweat, and tears -- but it was worth it to support such an awesome endeavor.

The new frontier

Until 1SE came along, Touch Lab had never worked on an app with video editing capability (although we had created videos on a server and worked on plenty of video displays).

Luckily, I had an ace up my sleeve to help us make sense of the process: my brother, The Honorable Frank Galligan, runs the WebM video codec team at Google. Frank broke down the components of video encoding for us, basically distilling months of open source info that would have taken weeks to wade through.

But even with a video expert on hand to explain the basics, the execution was ... intense. It would have been much easier to use VP8, WebM’s open source video compression format*, but we decided not to because it’s pretty much only supported on YouTube. To make sure our users can share the video on other platforms like Facebook, we had to stick with H.264.

Breakdowns and breakthroughs

Unlike iOS, Android doesn’t have much in the way of video editing capability built into its API.  Over several weeks, we had to piece together various tools and techniques that would allow us to cut exactly one second of video, starting on an exact frame, and figure out how to merge them together in a reasonable time frame.  Also, even we were surprised at the subtle variations of video output formats across manufacturers.  In general, Android “fragmentation” is overblown, but video is very much an exception.

In addition to months of good’ ol trial and error,  I credit our eventual success to two things:

The Touch Lab team: without a razor sharp -- and dedicated -- team, this app would still be just a figment of imagination.  The 1SE app is truly everybody’s baby, because the team shared in the collective head banging.  When one team member got burnt out on video format hell, I assigned it to another so they could tackle it with fresh eyes.

One too many late nights: in particular, one 4AM epiphany in which I finally figured out how to seamlessly sync video and audio. (Sorry for the victory shouts, neighbors.)

Secret sauce

I’d love nothing more than to divulge the geeky details of how we made this app happen despite a steep learning curve and Android’s limited video editing capability -- not to mention the surprising variation of video formats across manufacturers. But while I hope to share them very soon in the future, we’ve decided to keep the specific how-to underwraps for now so 1 Second Everyday can get some traction before 10 copy cats come out. (Plus: we’re a consulting company, and it’s always nice to make payroll.)

Despite the frustration, am I glad Touch Lab took on the challenge? Hell yeah. Not only did we get the satisfaction of solving an intractable puzzle, but now we get to kick back and watch it impact users’ lives, second by second.

*Footnote: I really hope WebM takes off.  Having a license-free codec, with pretty solid hardware optimization, would make life easier.  vp9 compression is crazy.  Watch this video: Its like ½ to ⅓ of what h264 can do (to be fair, h265 will probably be similarly awesome, but vp9 is coming sooner, and again -- it’s free).

——————————————————————

Looking for a great team of focused Android experts to bring your idea to life? We do one thing: make Android apps. Keeping that focus means we can do things the right way. Let's chat about your project, get in touch.

——————————————————————

Are you one of the best Android developers out there who likes solving problems, working on a small, agile team and building only the best solutions? Maybe we should talk, get in touch.

[touchlabblog]

No connection? Big problem.

This is Part 1 of 3 in a series on Offline Connectivity. Read Part 2: Offline functionality is a no brainer (and how Twitter dropped the ball) Read Part 3:8 Tips For Building a Badass Offline App ------------------------------------------------------------------------

The first step to fixing a problem is admitting that you have one.

Losing our home or work Internet connection is now as rare -- and inconvenient -- as losing power. When it does happen, we’re faced with a serious problem because we rely on our data to be accessible 24/7. But that level of trust doesn’t apply on-the-go: unless you’re a serious agoraphobe, you know what its like to lose your connection multiple times in one day.

Despite the fact that our mobile and WiFi connections are anything but a sure thing, we keep building apps that assume they are.

We’re not as connected as we think

For a moment, consider your ...

Mobile connection: You can access your data on your phone any time -- unless you happen to be on the elevator, in the subway, driving through the “sticks,” or hunkered down in the back of the gym by the old Stairmasters. And don’t forget that moment right after midnight on New Year’s -- not to mention all the times when your connection just stops working for no obvious reason.

WiFi connection (on your laptop, tablet, or phone): Ever ride Amtrak to upstate NY? Forget about checking your email. Wireless on a plane is a damn miracle -- when it’s available. (Just 24 percent of domestic flights currently offer it.) Consider, too, the connectivity issues you’ve probably encountered at tech conferences and presentations.

Finally, what happens if your server goes down or gets swamped?  Your disk runs out of space? The EC2 gets “flakey”? (I’m not even going to get into the havoc wreaked by freak occurrences like Hurricane Sandy.)

Development teams don’t get it … yet

I’ve talked to many development teams about this problem, but so many just shrug their shoulders. It’s easy to think connectivity issues “aren’t that bad” when you build and test your apps right at your desk,  sometimes when the server is even running right on your machine! (I’d bet my retirement fund most developers haven’t ever seen their own apps crap out mid-process.)

I’ve also been told “Networks are getting better all the time, and this won’t be an issue forever.” I’m sure this is true, but how long do we we have to wait -- five years? 10 years? It’s an open question, as is the definition of “better.” If you think the network problem will be eradicated within six months to a year -- the future time period all app development teams should be gunning for anyway -- you’re in serious denial.

Constant connectivity may be the wave of the future, but the future isn’t here yet.

What happens next?

Most frustrated users won’t complain about connectivity issues to you -- they’ll just stop using your app. But if one smart development team begins to adopt offline functionality into their best practices, more and more will follow suit. Users will quickly get used to apps “just working,” and those that design mediocre ones -- when it’s actually pretty easy to make great apps -- will fall behind.

The bar will be raised -- might as well start practicing your jumps.

  ——————————————————————

Are you one of the best Android developers out there who likes solving problems, working on a small, agile team and building only the best solutions? Maybe we should talk, get in touch.

[touchlabblog]

Static Application Reference

I'm a bit of a stickler for passing Context around methods rather than keeping a handle on the context in object fields and whatnot.  There are some obvious reasons, like being careful about memory leaks and whatnot.  I feel like its mostly because I like to be intentional about such things in code design.

However, as time goes on, I start to question some ideas.

The worst thing about the code was that the Context instance was being set in the launch Activity (which was a splash screen, btw :P ).  The obvious problem here, dear reader, is that you don't always go through the launch Activity when the app starts.  You may reload from the Activity that was last visible, when Android shut your app down.  Of secondary concern was that the Context instance was the Activity itself, which is just bad news (memory).

Anyway, I have this reflexive aversion to keeping Context objects anywhere in fields, much less in statics.  But, sometimes in life you need to question your views (and not start a sentence with 'but'. But, whatever).

What about keeping the Application instance in a static in a custom Application class?  Set it during onCreate.  From a technical perspective, I have a hard time coming up with a reason why you shouldn't do that.  There won't be memory leaks associated with doing that.  Unless there's a tear in time and space (or a bug in Android), that method will always be called, regardless of what Activity you're being dumped into.

From a design perspective, it feels lazy.  Thoughts?  Leave in comments!

Full disclosure, while I was actually thinking about this topic, I posted it because I wanted to try out the newly added comments section.

[touchlabblog]

Premier Clients: Meet Cesar Kuriyama of 1 Second EveryDay

Great guy, great moment

Two things stick out in my mind about getting in touch with Cesar Kuriyama. First, I'd seen his Ted2012 talk, really impressive. Check it out if you haven't seen it (also check out his bio, can't wait to see what's next from this guy):

The second thing was that not only did I get along with Cesar right away, but I got one of those great New York compliments. I found out that everyone he spoke to in tech told him he should talk to us about building a premier Android app. Very grateful to all the great people who recommended us and thanks so much Cesar for putting it in writing on your kickstarter page!

  One Second Everyday

1SE already had a great iPhone app and we were really happy to bring it to Android. After the initial discussions, we got the opportunity for our creative director, Paul, to really dive into the design and make sure it was a true Android experience (not just a ported iLook).

Cesar is presenting the app tonight, June 11th at the New York Tech Meetup (congrats Cesar!!) but in case you miss it, here's a few screens for you:

Solving development challenges

The types of projects we like at Touch Lab are the ones where we get to push and make things happen that no one else could. Luckily the 1SE app gave us a few major challenges to solve. Here's three, for those of you that like this stuff:

iOS has libraries for cutting and pasting videos; Android, not so much. We had to pull together various utilities to get that sorted out. Because of that, cutting the 1 second clips is a little slower than iOS, but compiling videos on Android is MUCH faster ;) 

Audio actually ended up making the compiling even more difficult because while the video cuts to exactly 1 second, the audio has a few ms left over. That's fine with a few videos, but with hundreds, it adds up. The solution is took a while, but it works great now.

Because of the way video is encoded on Android, it doesn't start exactly when you want. When you say "start at 21.43", Android finds the next key frame, so maybe it'll actually start at 21.57 and play for a little under a second. Our team did a little movie magic and got that video to start exactly when the user wants and play for exactly a second. 

The app is still in beta, but as soon as it's on the Play store, we'll update here with a link.

Congrats again to Cesar on One Second Everyday! We'll be keeping an eye out for your next amazing project.

--------------------------------------------

Are you one of the best Android developers out there who likes solving problems, working on a small, agile team and building only the best solutions? Maybe we should talk, get in touch.

[touchlabblog]

App Data Encryption

We're working on an app that requires local data to be encrypted.  Till now, the solution has been using the username/password combo to be the ultimate source of the encryption key (I'll spare you the process of going from u/p to key, but safely assume its sufficiently boring and secure).  The u/p combo is kept in memory, so if somebody stole the device, assuming the password was sufficiently complex, its beyond unlikely that they'd ever crack it.

Now we need to implement some form of SSO.  That means we don't get the password.  Only some form of key to use when talking to the server, which changes periodically, and is generally not used for the hacky thing we want to use it for.

We *should* be able to keep the Encryption key in the KeyChain, and tie it to the lock screen, but as far as I can tell, that's not possible (if so, PLEASE correct me).  That would let us enable the lock screen and do what we want to do.

Since this app needs to be secure, enabling the lock screen is pretty much a given anyway.

However, its all more work than it needs to be.  We *could* force the user to encrypt their whole disk, but that's a crazy long process, and we couldn't programmatically verify the disk was encrypted (again, I think we couldn't. Please correct if I'm wrong).  Without being able to verify, this wouldn't fly.  Plus, nobody would be OK with the process.

If I could have one wish for my birthday (its not my birthday), it would be a way to enable local data encryption for a single app.  All of it.  When you go to run the app, it dumps into the same sequence as when you go to add a cert to the KeyChain (or something similar).  You are forced to enable the lock screen (assuming you haven't, of course).  The Android runtime then encrypts/decrypts your data seamlessly.

That would be sweet.

[touchlabblog]

Data Synchronization

I haven't been blogging much.  I suffer from what we've termed the "Great American Post Syndrome" (GAPS).  That is, every blog post needs to be the best piece of technical literature ever written, so you actually never post anything.

So, the result is few posts, but a large drafts folder.  Looking through it, judging by volume, I must think HTML5 and offline data synchronization are REALLY important topics.

Lately we've been working with a client on HTML5 (yes, its a scandal).  A lot of that work has to do with applying mobile lessons to HTML5 development.  Just because you're building a "web app" doesn't mean you suddenly don't have to worry about being offline.  Some day we might chat about how to do this in HTML5, but since syncing data needs to happen in both contexts, and the concepts are pretty similar, we'll start there.

This will be a multi-part series.  One way to avoid GAPS is to write little bits and try not to take any particular one too seriously.

BTW, I swear GAPS is not a Backronym. I didn't even notice it till I wrote out the letters.

Definition

Synchronizing data is a big topic.  It means different things to different people, and is obviously framed by projects they've worked on.  In our cases, it generally means one or more data entities in database tables.  Data may be entered locally, pushed remotely to a server, and mixed and pulled back with data from other users that could conflict.  There are probably relationships between the tables, and specific business logic around entities.  Summary, "synchronizing" is not as simple as copying data up and back to the server. It may also include data outside of the database, like image file uploads.

On top of that, you often don't control the server API. Basically, it ranges from "difficult" to "captain, we've lost the hydraulics".

Changes to data should be possible offline.  If you're not supporting that, stop reading. You aren't synchronizing data. You're writing a web app. If your users are on mobile devices, they will curse you often, but supporting offline data is difficult and time consuming. You decide.

The basic workflow is:

Update data from the server (periodically)

Add/Edit/Delete data locally

Push these changes to a central server

It seems like something that should be pretty simple, and sometimes it is. If you only have one or two tables, and if your user's data can only be edited by you, or if data is only rarely changed, this can usually be handled with some manual code.  When your app gets significantly more complex, you'll find syncing becomes difficult, but not only that.  You'll have weird issues that are very difficult to debug, because they don't come up in testing and are pretty much impossible to reproduce. You should implement robust error and crash report, but that's the topic of another post. I am STUNNED by how many app projects we jump on that don't have crash reporting. If your method of error reporting is one-star reviews, somebody needs to throw you an intervention (hmm. Reality show? App Rescue? I think I could yell at people).

Methods of Synchronization

There are probably several more ways that you could manage your syncing, but I think there are basically two methods: state-based (SB) and command-based (CB).

SB is the most obvious method.  When its time to sync with the server, you crack open the db and look at the tables to figure out what needs syncing.  This requires, at a minimum, a "dirty" flag column. That might be simply that, but often its an "updated" column with a timestamp.

This "works", and is the most obvious solution.  Query the tables, push data. Done. However, it can get tricky when you have multiple tables, and when those tables relate to each other.

Imagine an app with a Company table and a Product table.  You can't create a product without a company, so when you run your sync, you need to make sure you do things in order. That's easy enough. Just query by the "updated" column.

Now, imagine you create a company, then add a product, but then update the company.  If you simply use "updated", your sync will fail.  Now you need to keep an "added" and "updated" field, or you need to send the company info on each product add, or something more painful.

OK, that sucks.  Now the "business" wants to have a "main product" field added to the company table.  Whoops.  Circular relations.  Then you need to throw in the other 10-20 tables that a "mature" app inexplicably seems to grow, and deal with their data and temporal relations.

Also, maybe you just want to edit the name of the company, and somebody else edits the address.  Since nobody is keeping tabs on what data was edited, the sync will fail, but you can't shake the idea that if you'd add a little more info to your table you could do this properly. So now there's a "nameUpdatedAt" field and an "addressUpdatedAt" field.  Seems reasonable.

Then a new developer starts and over the next few weeks you swear you hear her saying "what is this garbage?" under her breath, over and over.

If you're remotely awake and reading this, you'll probably guess that I think CB is usually the way to go, but before we get into the details, I'll say that simpler data is probably better handled by SB.  With one or two simple tables, and a fairly infrequent update schedule, or a small number of users, state-based is obvious to code, and has a "safer" feeling. The dirty flag doesn't get cleared until you get an affirmative from the server. If you're debugging your app and you want to see a snapshot of current status, simply query the db. Simplicity is valuable, so long as it actually is as simple as you want it to be (that's another syndrome that needs a name. Coding things to be as simple as you want them to be, rather than accepting their actual complexity and dealing with it. Todo: make a backronym from CRAPS or something similar).

Command based is what I'd call a "pulling the sock inside out" approach. If we had some magic computer science complexity evaluation device, properly syncing data with either method would probably look exactly the same, stripped down to its core operations. Only the way its done is different (and much easier to comprehend).

CB works as follows.  Rather than look at the state to figure out what you need to do, you record "what you need to do", as commands. When you add a company, you push the "AddCompany" command into a queue. When you add a product, the "AddProduct" command.  Update the company? Shocker. Push the "UpdateCompany" command.

In its simplest form, these commands get played back in the order they were added.  The part about this being an inside-out sock is that with SB, you're generating a list of commands from the data state.  With CB, you're simply recording those commands when the actions happen.  At the end of the day, what gets pushed over the wire is roughly equivalent.

The reason why this is better is because you don't really need to deal with the complexities of your data relationships, or with temporal issues (by "temporal" I mean "this needs to happen before that". Its pretty rare that you can say "temporal" with a straight face in a non sci-fi context, so enjoy it. You're welcome).  Also, if you wanted fine grained operations, you can split out updates into different commands.  You could have an "UpdateCompanyName" command, for example.  As with most things in life, the 80/20 rule applies here.  Maybe you put the extra effort in for one or two main tables, and do course grained updates on the rest.

You can also write commands for stuff that isn't kept in the DB. Image uploads, again, are the common example.

The benefit isn't free. You need to implement a rock-solid queueing system, that includes storing commands, dealing with errors, etc. If you have a bug in your queue code, you could lose updates.  SB has the advantage of safety, or at least the impression of safety.  You don't clear the dirty flag until you get an affirmative response from the server.

Fortunetely, the parts of a CB queue that need to be rock-solid are pretty common across implementations, and we've built one.

https://github.com/touchlab/Superbus

Its overly complex right now. We've had a few iterations, which has resulted in several options for storing command data. I may trim all but the safest, which is SQLite. File based is OK, but with SQLite, you can include command data updates inside of your data transactions, so command and entity state changes are atomic.  Properly implemented, this should ensure the state of the command queue and your own data remain in lockstep.  Of course, I pretty much guarantee you'll have logic issues when implementing your sync queue. Especially if its your first time.

But if it was easy, everybody would do it.

Later in the series, I'll cover a basic implementation and talk about common pitfalls.

[touchlabblog]

Boot Camp

We've been throwing around the idea a "boot camp" for advanced Android for a while now.  Its been slowly brewing, but its time to pull it together.

We're making a list of topics that a serious Android developer should be familiar with, but would like some feedback from the community.  What have you learned that you think a serious developer should know?