Porting an iOS app to Android means frequently translating between the divergent UI paradigms of the two operating systems. Both platforms encourage developers to follow certain interface guidelines, but clients sometimes prefer replicating a familiar interface. Thankfully, Android offers fairly deep customization.
For one port, the Android app needed to use the same view transition animation as its iOS counterpart.
On iOS, the standard navigation stack defaults to animating a detail page transition (called by
[UINavigationController pushViewController:detailController animated:YES]) by sliding the detail view in from the right, and the root view out to the left. Navigating back to the root view (
[UINavigationController popViewControllerAnimated:YES]) reverses the animation, sliding the detail view out to the right and the root view in from the left.
On Android, the same transition (handled through a FragmentTransaction) defaults to a zoom animation, or sometimes a slide up animation. How can Android mimic iOS’ transition animation? (more…)
Art & Logic is once again trying to be selected to present a panel discussion at next year’s SXSW Interactive Festival in Austin. In 2014, we had a great experience there talking about things we’ve learned about doing estimates for software projects.
This year, we’ve prepared a proposal for a panel to be called “Office Free: Building the Perfect 21st Century Company” that will cover some of the lessons (and anti-patterns) about operating and working in a completely distributed company that we’ve learned over the last 25 years. (more…)
You may remember my post from a while back about my experiences writing a Twitter bot. On my desktop, I keep an instance of TweetDeck running throughout the day, and one of its columns is set to view the notifications for @tmbotg. One of the bits of code in the bot is that any time another twitter user @-mentions the bot (or does an old-style “RT” retweet), the bot creates a favorite for that tweet. Recently I’ve noticed that retweets have been showing up in that column, but not getting faved. What’s up with that? (more…)
While preparing some documents today I ended back here on the blog reading two posts from last year that are still fresh and deserve a second (or first, if you missed them the first time!) look.
First, a post I wrote while waiting at the airport for a flight to SXSW 2014. That flight ended up being so delayed that I came closer to missing the panel I was speaking on than I care to ever repeat again:
Thoughts on Estimating Software Projects
To be honest, while I’m excited to be speaking at SXSW, I wasn’t at all excited at first to be talking about this topic; it’s an area that’s not considered ‘cool’ in modern software development circles. The most obvious indication of this attitude is an article in a recent issue of Pragmatic Programmer Magazine by Ron Jeffries titled “Estimation is Evil: Overcoming the Estimation Obsession.”
…and a follow-up post a week later by Noah Miller talking about our guidelines for writing useful and meaningful requirements docs for software projects:
Thoughts on Writing Software Requirements
Writing and estimating requirements is painful to most everyone involved, highly problematic, totally not hip – and essential to well run projects.
Check them out.
Image by https://www.flickr.com/photos/gazeronly/
So you’re asking yourself – robot or real person?
When it comes to user accounts, the standard litmus test is email validation. Besides the immediate benefits – of offering us a straightforward unique identifier for users, and making it more difficult to automate creating a mass of accounts on our service – by requiring that each account have an email address and interact therewith to confirm the addresses validity, it also offers us the chance to associate a known-working email account with a user account. This is important for transactional emails such as password resets or for potential two-factor authentication use… and if you’re a little less ethical, for sending
marketing desirable and informative emails about interesting products and services.
“But,” you whine piteously, “the whole reason I integrated python-social-auth into my project was to let the OAuth providers look after this sort of thing for me!”
Tough rocks. Twitter ain’t gonna give you their users’ email addresses. Just look at all those angry comments. If their whining didn’t get through to Twitter, yours isn’t going to do the trick either. Besides, eventually you’ll probably want to allow the user to login the good old-fashioned way, with a username (which may or may not be their email address) and a password – in which case, you’ll want to handle validating their email address yourself anyways.
So, given that we’ve already integrated python-social-auth into our Django project (some of the same principles will apply to other frameworks, but many of the details presented herein are specified to Django) – let’s get email validation working as part of our user creation/authentication pipeline.
What’s the best type of refactoring you could ever perform on source code? Silly question, right? The best answer I’ve seen is to delete some of it. (more…)