I installed the latest Adobe AIR installer, v1.5. Turns out Adobe AIR changes your default keychain from login to something else, which then completely breaks all Xcode signing.
To resolve this problem, open up Keychain Access, then right-click on the login keychain. Select “Make Keychain ‘login’ default” in the popup menu.
Then go back to iPhone development.
On Windows Mobile 5 (and I assume the same is true of 6 and 7), the small bar at the bottom which shows the current meaning of the two smart buttons is not a separate chunk of real estate taken away from the rest of the application; instead it is a floating HWND object. It is up to your application to know if that HWND object is present, and to make sure you don’t obscure the HWND.
On the iPhone with the v2.2 and v3.0 OS, the slide-up keyboard is essentially a floating window which overlays your UI. It is your responsibility to know if the keyboard is present, and if so, resize the contents of your view accordingly. That means if you have a table view with an edit text field that is graphically in the area where the keyboard will appear, you have to figure out a way to move the table contents up and down as the keyboard appears and disappears.
I contend that the region of the screen devoted to the keyboard or custom keypad or the like should not be handled as pop-up windows overlaying your user interface. Instead they should be handled as events that resize the main “window” of your user interface. And instead of hooking a half-dozen different events that could change the form factor of the screen, all of these events should be handled exactly the same way they’re handled on a desktop application: with a resize event sent to the “window”, which then percolates down the view chain.
Unfortunately it appears no-one agrees with me. And so we’re stuck doing all sorts of complicated stuff–including Android, which tears down and rebuilds the “Activity” (the thing which manages the views in a UI) rather than simply send a resize event.
*sigh*
I hated to do that.
But for some reason or another, thanks to spam scrapers and the like, I was getting so much spam on that e-mail address that I couldn’t sort out the real messages from the Spam.
Even thanks to Google’s spam filtering and to Apple Mail’s junk mail filtering I was still seeing 200 messages a day on that address–all spam.
I’m sure there was some real messages in there somewhere, but sorry; I didn’t get them. If you sent me a real message, it was probably buried under offers for Viagra, free money, and offers in Spanish and Russian and Chinese I couldn’t read.
During tonight’s iPhone judging contest, one of the projects was one which handles personal information in a way which requires a fair degree of security. Unfortunately I didn’t have the time to make some simple observations about security, so I’ll note them here instead. So here are some simple security rules of thumb:
(1) “Never underestimate the power of human stupidity.” — Robert Heinlein.
(2) Security by obscurity simply gives a single point of failure. That includes things like “hidden” encryption keys.
(3) Unless you have a degree in Mathematics with a specialty in abstract algebra and encryption algorithms, and later either got a Ph.D. in encryption security or apprenticed at the NSA for a few years, do not create your own encryption algorithm. (These guys invented their own system, and how many microseconds did it take to break it?)
(4) Always salt your passwords: One-way hashing never is.
(5) Never pad your blocks with zeros.
(6) Be aware of man-in-the-middle attacks and design to work around them.
(7) Two factor authentication means something other than what the banks think it means.
(8) Security only increases the cost to break in a system: if you put something behind a security barrier that is worth more than the cost of breaking the system, someone will break it.
(9) Social engineering is your greatest enemy. The best key lock systems protected by armed guards, security cameras and a barbed wire fence won’t protect you against a helpful employee who holds the back door for some nice young man.
(10) If you don’t understand the stuff above, for God’s sake, hire someone who does.
This evening I’m going to USC to judge an iPhone development contest being held at USC. It should be interesting–and a lot of fun. Part of my goal is to keep an eye out for good talent we may want to poach, and part of my goal is to judge the applications according to concept, user experience, implementation and business model.
Now me, I’m not good on the business model side of the fence: I tend to think of a business model as being “make a good product and sell it for a reasonable price”, which means half of the business models used nowadays in the tech industry makes no sense to me. But what do I know? On the other hand, user experience, and implementation: now all that I’ve got in spades, and I intend to be an opinionated bastard tonight, turning it into a teachable moment if at all possible.
Because I have a whole bunch of technical documents that I’d like to be able to carry around and read on a device that is not my laptop.
(And yes, I could have ordered a cheap touch-screen laptop, but I’d also like to be able to order and download books from Amazon as well as O’Reilly (who makes their books available as PDFs at a discount) as well as papers from ACM. The ePaper screen also makes the thing highly readable outside.)
This was driving me nuts all weekend, because I became misguided.
On Google Android, I want to create a custom list view, and I want to handle context menus. Of course the right way to do this is:
(1) In your activity that contains your list, call setOnCreateContextMenu with a class that will be handling the context menu callbacks. (The activity already implements the interface, so you can just pass it your activity.)
fListView.setOnCreateContextMenuListener(this);
(2) Implement the onCreateContextMenu and onContextItemSelect items as usual.
Where I ran into problems was with another suggestion from another web site that suggested in my custom list adapter that I call the view’s registerForContextMenu routine. The problem with that is that you don’t get the list view’s yellow highlight and animated fade effect.
One foot is by definition 0.3048 meters.
If you write
feet = meters * 3.28;
instead of
feet = meters / 0.3048;
Why, other than sloppiness? I mean, both operations take the same number of clock cycles, but the former is numerically wrong.
Why Is Venture Capital Under Assault?
Generally I don’t post political commentary in this blog (I do that elsewhere), but, um, ah, most of the people in Silicon Valley voted for President Obama despite knowing the sort of critter they were voting for.
You get what you pay for.
Way back in June when I started working for the startup I’m working for now, I made an observation about how people will use their smart phones–a fact which was ignored, and which I believe is hurting our app now. And it reflects how we use different computing form-factors in general.
A desktop is not a laptop is not a pocket computer.
A desktop is an immersive environment. Consisting of a very large display screen and keyboard, a desktop computer is something that generally has a fixed location, but can have a lot of attached or non-portable devices that allow you a great deal of power. Desktop computers are perfect for the daily grind of working at a fixed location.
Laptop and portable computers are less immersive simply because they are smaller. In general, you use a laptop computer by sitting down at a given fixed location, setting up your environment (pull out laptop, open it up, turn it on, find a wireless connection, plug it in), and working. Battery life for a laptop is not all that important unless you set up in an area without an outlet–at which point battery life is invaluable. Battery life is also invaluable if you use a laptop to go from meeting to meeting, where setup time needs to be as short as “take out, flip open.”
Phone computers are the least immersive device, and the one that interests me the most because it is the one that is the least understood. The few people I’ve talked to about phone computers have talked about creating compelling immersive environments for the phone–and tackling the problem of figuring out how to create an immersive environment on a tiny form factor. But phone computers are not immersive.
Certainly there are “immersive” games being designed for the iPhone computer. But there are also a lot of people who seem surprised that some of the most successful applications for the iPhone are things like fart jokes. The reality is that these successful tiny applications are not simply successful because the App Store is improperly structured–though this contributes. No, they are successful because people use the iPhone differently than they use laptop computers.
You see, most people use the phone in the following way:
(1) They pull it out of the pocket and press the “unlock” key.
(2) They tap a few keys. Perhaps they’re getting someone’s phone number, or placing a call, or pulling the finger.
(3) They then put it back into their pockets.
In other words, the tiny, non-immersive form factor combined with a non-existent setup time (as compared to laptops or desktops) means that most interaction with the phone is going to be a very quick cycle of “pull it out, ask a question, get an answer, put it back.”
Now there are times when people are using their phones for an extended period of time. But that extended period of time will stem from two sources. First, a user may be stuck on a subway or in an airport and have nothing to do–at which point they’ll use the phone as a source of entertainment. They’ll pull it out and watch a movie or TV show, or browse the web, or play a game. Because they’re in a circumstance where they’re killing time, however, the game or program should be able to save state quickly, and be entertaining immediately. A first person shooter that has no objective but quickly blowing people away makes more sense than a ‘capture the flag’ game or a game which takes some extended period of time to complete the level: you don’t know when the user will be back on the subway or stuck in an airport. And he may only be killing five minutes.
The second reason why a user will continue using an application (IMHO) is when he pulls it out, asks a question–then doesn’t get the answer he’s looking for, so re-asks the question in a different way. But this is not a good model of user interaction: the user is not interacting with your application because they’ve suddenly gone into an immersive interaction. They’re frustrated! because they’re not getting the answer they want.
Because of this, information-providing applications should provide information quickly. All the usual rules of computer-human interaction apply: 1/4th of a second is the longest delay between touching something and having it react. Two to four seconds is the longest delay for doing some computation–and during this time a spinning animation should be shown. If there is something that requires more time (such as getting the GPS location or hitting a server), a status display should be put up if this takes more than 5 seconds, letting the user know exactly what the software is doing. And if the entire interaction takes longer than perhaps 15 seconds, you better have a very good reason why–because chances are the user is going to flip the application off and put it away, unless he really needs the information.
But the bottom line is this: if your application provides information, it needs to work in a very quick cycle of “pull the phone out, ask a question, get an answer, put the phone away.” If you are designing your application to be an immersive environment or to function in any way other than in a “pull it out, ask a question, get an answer, put it away” loop, you’re designing your application for failure.
Development Chaos Theory 