iBranc.com

This quick update turned out to take a bit longer than anticipated.

The primary addition is the option to enable "contains" search for names.  This was introduced in 2.5 and removed in 2.6 due to the volume of search results often returned.  However, enough folks protested so its now an option (which is what I should have done in 2.6 - lesson learned).

I also found and fixed a memory leak during sync which was causing some crashes.  Let me know if you used to have sync issues but no longer do with 2.7.

Finally, one of the biggest, perhaps controversial change is the View/Edit features.  Per my forum post, there are problems associated with certain services, mainly MobileMe.  This service has no concept of a consistent unique identifier, which means that when you click the View/Edit button it would often no longer be there!  This is why it would break and give you an error message.  However, this works just fine for other services, such as Exchange. 

Therefore, I decided to make View/Edit an option that defaults to Off.  I couldn't see how I could go backwards and pull it entirely.  However, its very confusing for MobileMe users as there is no workaround for this.  No unique ID is a killer - at best I could guess based on name but that would fail certain percentage of the time.  So, please enable it until you detect its not working.  If I have some flash of brilliance and find a way around this, I'll be sure to update the app.

 

Happy to announce that SD2.5 is now available on the AppStore, in record time I might add.  Took 3 days for approval this time; great to see Apple making progress on this.

There are a ton of new features in this version, based entirely on feature requests from users.  First, I made some changes to how and what its searching.  At the highest level, SD does two types of searching: "Contains" and "Begins With".  They are what you probably think they are, and i'll use those terms to explain the changes.

I've included Notes now, so it does a Contains search on your notes for the search term.  This can lead to a lot of search results so you can optionally turn it off.  Also, I now do a Contains search on the full name and Company name rather than just begins with (search by initials still works).  This was done to accommodate middle names and multi-word names better.  Also works for entries like "Bob and Sue".  I now am ignoring all punctuation when searching, so O'Brian can be found by typing "obrian".  Also works for people who use punctuation to group contacts together.  Note you can also search with the punctuation - works either way.

One big improvement is full extended character support.  There are many users who's entire contact database is in a localized language requiring unicode characters (Russian, Hebrew, Greek, etc).  This now works - I store and search UTF8 characters.

In addition to these search changes, there are a few significant new features.  You can now View/Edit contacts directly within SearchDial.  When you click the Blue Arrow from the search results table, it takes you into this view:
From here, you can click the Edit button and edit the contact as if you were in the native Contacts app.  Any changes you make here update your main address book as well as the SD cache so you don't need to refresh.  There is no default support for Delete but I'm working on that for a future release.

Also, you can now search using T9 syntax on the dialpad.  This lets you quickly find things using bigger buttons - much easier to do one handed.
Notice how hitting the numbers 5 2 find both John Appleseed (JA) and Kate Bell (KB).  That is because 5 searches everything with a JKL and 2 everything with JKL.  This means 52 does JA, JB, JC, KA, KB and so on.  Its actually very efficient once you get used to it.  This is a mode you have to turn on in the Settings.  Its off by default, giving you a normal keyboad.  But if you enable this setting all 3 modes will use this keypad.  The only limitation is that you can't use DirectEmail while in T9 mode.

One cool new feature is that SD will remember your last search only when you call, SMS or Email someone.  This means if you search for Jeff (and it returns a Home and Mobile number) you can dial Home.  If they don't answer, you hang up and when SD reloads its right back where you left off so you can just hit Mobile.  When you do a normal exit without calling anyone, it clears this and starts with the default AutoFavorites screen.

Also, in addition to choosing your default mode (Call, SMS or Email) you can set it to remember the last mode used.  This will always start up SD in whatever mode you were in when you exited.

There have been numerous minor fixes that I hope you notice over time.  As always please email me at support@ibranc.com if you have any issues, questions or requests.

One final note: there are a number of comments on iTunes from the inital 1.0 broken release.  If you made one and SD is now working for you, I'd appreciate it if you updated it with your current thoughts.  Thanks!

 

There are a few sites out there for iPhone apps outside of the AppStore itself.  They offer a lot more in terms of community features to rate and discuss apps.

I finally finished SD 2.0 and submitted it to the AppStore on 10/12.  I suppose it will be another few weeks before this gets cleared.

Here are some of the top issues users wrote to me about:

1. Slow start times, or crashes, for large numbers of contacts (>1,000)
2. Search by intials (Johh Doe is jd, dj, jdo, djo, etc)
3. Allow a white background with standard blue controls
   
4. Search through special characters: typing e is the same as é or è, etc.
5. Do more than just dial - allow SMS, Email, Edit, etc as well
6. Erase all AutoFavorites at once, or disable them altogether.
   
7. Search the Notes field
8. Enter letters through a standard phone keypad (2=abc, 3=def, and so on)
9. When returning from a phone call, default to the last set of search results.
   

For 2.0, I tackled 1-6 (well, part of 5). 
This required a near complete rewrite focusing on fast start times for large numbers of contacts.  Rather than read the AddressBook into memory as 1.x did, I store a cached copy of the necessary fields in a local SQLite database.  This has the advantage of no overhead during application startup - 2.0 starts in the same amount of time with 10 contacts as with 10,000.  This also provides a lot of search flexibility, allowing more than the Address Book API calls support. It will also be easier to expand downstream by adding additional fields such as Notes.  The only real downside is that you have to manually sync SD with your Contacts.  This only has to be done when you change your contacts (and want to search the changed ones), NOT every time you run SD.  It's speedy up until a few thousand contacts and then starts to slow down.  At about 2,000 it will take 15 seconds.  At 10,000 as long as a minute.  Above 10,000 is unsupported, and will frequenly crash due to memory constraints.  It was a tradeoff I had to make based on the assumption that 95% or more folks have less than 10K contacts.  Comment here if you fall into the > 10K category.

I also made some big changes to the UI.  I have always been hesitant to use a toolbar or tabbar in order to maximize the vertical space, and therefore the number of contacts displayed while searching.  However, even more important is the notion of "one click action": find your number and tap it - no intermediary screens.  To resolve this, I implemented an "Action Mode" toolbar:
 
This works by letting you choose which mode you are in.  If you want to SMS someone, hit the SMS toolbar button, search and then select your contact.  You can also switch modes after searching.  SMS Mode will only display Mobile numbers, and Email Mode will only display email addresses.  You can specify the default mode on startup.  This lets you still get the benefits of "Start, Search, Connect" and the flexibility of other actions, and allows you to optimize the number of clicks for your common use case.

All 3 modes support the DirectDial concept in that if your search result is not found, you can finish typing the number or email address and connect accordingly.  I had also intended to include Edit in this release, but it was going to be a bit more time consuming than I first thought (at least to do it right), so its been pushed until a future release.

I included a few new settings (you get to settings through the main iPhone Settings screen).
From here you can choose a white background, turn off AutoFavorites, choose your default Action Mode, and set the colors as before, including email.

I also multi-threaded the search to allow you to keep typing while it searches in the background, and if you type fast enough and have enough contacts it will even attempt to cancel your previous searches in favor of your lastest one.  If you have 10,000 contacts you may see this in action; if you have < 500 you will never be able to tell.  Also if you have < 100 contacts it syncs with your address book so fast I don't bother displaying  the progress screen, so here is a good look :)

As always, comments and feedback welcome.  I really do appreciate the constructive emails, and very much appreciate those who volunteered to test my various betas.  I'd hate to do another 1.0 fiasco, so I am grateful.

Thanks to everyone who has taken the time to contact me with feedback and feature requests.  There are some definite common threads that I plan on addressing, so I thought it best to let everyone know what I'm currently working on.

Here are my priorities:

1. Improve performance for both startup and searching.
   
2. Provide search by initials (i.e.  search "jb" or "jbr" to find Jeff Branc)
3. Enable an "Action Mode" so you can choose what happens when you find/select your contact.  Current priority is SMS and Edit, but also working on Email as well.
   
4. Configuration setting for background color (white or black)

There are also a few bug fixes:

• Fix searching for first and last names that contain multiple words
• Fix searching names that contain extended characters

If you are encountering other bugs email me at support@ibranc.com so we can work through it, and get it fixed in the next release.

I'll provide additional posts with more details on #1 and #3 above - those are the most involved and fundamentally change the way SearchDial is currently architected.

The update was approved today.  Hopefully folks are able to upgrade - I know I've been seeing some very odd upgrade behavior with apps lately.

Let me know if you don't see 1.1, or are having issues upgrading.  Of course, also visit the forums if you have comments/questions/feedback on SearchDial

My past few experiences with the AppStore involved 6-7 day delays.  So far I'm on Day 10 of this update submission.

I wish I could tell you when the update will be out, but I have no idea, and no way of knowing.

Also, I've tried to be very clear here, in the forums, through email, and on the iTunes Store description that the current version has known bugs.  I don't know what else to do to make it more clear.  Comments keep rolling in, and they appear to ignore everything I've said.

a) Yes I did submit an update
b) No I don't know when it will be out
c) The current version on the store doesn't work for most users
d) If I take it down from the store, I have no faith the update will be processed at all, and no way of knowing in advance how Apple reacts to that scenario.
e) The screen shots are not fake per se - they contain sample data that comes with the default Simulator (app that lets you test the phone app on a Mac).  Since I'm dealing with contacts, I'm not exactly going to publish screen shots of my personal address book.

I know people are understandably frustrated.  I am frustrated as well.  I've sent repeated emails and phone calls to Apple and they simply do not respond.  Hopefully it will be "any day now".

Thanks to those who have been supportive, helped me test this update, and are patiently waiting.  I am committed to continuous improvent of SearchDial and the suggestions have been great.

-Jeff

In going through this experience with SearchDial, it highlighted a few things about the AppStore workflow that could use some tweaking.

As you can no doubt tell from the comments, the 1.0 of SearchDial had a critical issue - it did not show contacts for some (most?) users.  This was essentially caused by the way I was getting the contacts, and for 1.1 I changed to a new, better way.  Due to the nuance of the problem, it never once showed up in the local SDK simulator, my phone (and those that tested), or even in the AppStore testing.  I never looked for the better way because it never came up, nor would it until it hit a broader, more diverse set of phones and the variability that that gives you.

At any rate, I removed the app from sale until I could fix it.  However, this has 2 effects:

1. I could no longer communicate to users through the AppStore product description.
   
2. You cannot post an update to your app without making it available for sale again!

So, now I have an app out there with a known issue while I wait for Apple to approve my update, which can take up to a week or more.  I hope people can understand that I'm not trying to 'pull a fast one', its simply how the system works.

My suggestion to Apple is to amend their workflow to allow a Developer to suspend downloads.  This would keep the app in the store, allow the Developer to explain the situation in the Description, and then post the update and re-enable downloads when ready.

Another feature sorely needed is the ability to comment on comments, without adding a rating.  I see all kinds of comments I would love to respond to directly to clarify things but I have no chance to.