The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniFocus > OmniFocus for iPhone
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
Why is OmniFocus for iPhone's startup/sync time variable? Thread Tools Search this Thread Display Modes
Has there been any thought given to:

(1) an auto-archive preference.
(2) allowing archiving to a webdav server.

Both of these would encourage me to actually use the archive feature.

Edit: Actually, now that I think about it, why do I even have to maintain a separate archive? Why can't archiving be the equivalent of a "stop syncing this data" flag in the database?

Last edited by Chris; 2009-05-03 at 10:27 AM..
 
Quote:
Originally Posted by Chris View Post
(2) allowing archiving to a webdav server.
Care to flesh out this vision a bit more? Do you see this as providing something more than allowing you to execute the archive command and look at archived on any of your clients?
Quote:
Edit: Actually, now that I think about it, why do I even have to maintain a separate archive? Why can't archiving be the equivalent of a "stop syncing this data" flag in the database?
Because I can attest from personal experience that OmniFocus runs glacially when you start having > 10,000 actions in your database, even if most of them are out of sight! Getting an iPod touch forced me to do some heavy-duty archiving, but having slimmed down to about 2,800 actions (10,000 in the archive!) the iPod works fine, with a startup time of about 6 seconds, and the MacBook is like a new machine.
 
So I read Brian's note, went to "Move Old Data to Archive..." on my Mac and saw this: "You should always archive on the same computer. This ensures that you will have a single archive file containing all of your historical data." I'm at home, so I was immediately confronted with the question "Do I want this archive on my home machine or my work machine? Which would be better? Where am I more likely to want to access the archive?"

Then I thought "Why do I even need to worry about this? I sync to a webdav server. Why can't I keep my archive there and avoid this decision completely? Why should the user have to worry about this at all? It's certainly not helping me Get Things Done!!!"

Then I thought, why not just keep a master database on the server I'm syncing to that holds all my actions (archived or not). Then only sync to the clients the ones not flagged as archival and all the client databases will be small (especially if there's an auto-archive preference). The user wouldn't have to worry about which machine the archive is on and could access the archive from anywhere. That was the idea for the thought added in the edit.

In the end, the existence of this thread (combined with the slow start up times for OF on my iPhone) says to me that something's broken with the current archiving and syncing paradigms.

Last edited by Chris; 2009-05-03 at 12:05 PM..
 
Quote:
Originally Posted by Chris View Post
Then I thought, why not just keep a master database on the server I'm syncing to that holds all my actions (archived or not). Then only sync to the clients the ones not flagged as archival and all the client databases will be small (especially if there's an auto-archive preference). The user wouldn't have to worry about which machine the archive is on and could access the archive from anywhere. That was the idea for the thought added in the edit.
There's certainly some valid reasoning behind the idea of keeping it all on the webdav server where any client could get at it. It might not even be all that much trouble to implement, as such things go. I'm not sure that they should be commingled, however, based on the performance I saw with a larger database.
Quote:
In the end, the existence of this thread (combined with the slow start up times for OF on my iPhone) says to me that something's broken with the current archiving and syncing paradigms.
What kind of start up times are you getting, and what size is your database (both actions and megabytes)? What does it have to be for you not to regard it as slow? I'm pleasantly surprised by how well it performs for me; the only painful spot is when the iPod compacts the database (I'm syncing to MobileMe, not Bonjour) and that doesn't happen very often.
 
It's pretty variable. When I started trying to use OF on my iPhone, I quickly reset the time-to-lock on the phone from one minute to five minutes because it was taking well over a minute for OF to be responsive.

This morning was about 15 seconds. That's with just under 2000 actions and about 15 zip files in the database. The .ofocus file on my Mac is 1.4 MB.

But like I said, it's still pretty variable; I guess that's what I find frustrating. I never know how long I'll have to look at that spinning wheel before OF becomes responsive on the phone.

Edit: Here's what I mean about variability. Later this morning, essentially the same database (had only completed a couple actions this morning, didn't add anything), startup was about 1 minute.

Last edited by Chris; 2009-05-04 at 07:21 AM..
 
I wonder what the difference is between our environments that causes you to get the relatively sluggish performance? I consistently get a startup time of 5-6 seconds. 374 projects, 2621 actions, 63 zip files, 2.4 MB. I have a decent DSL connection (4.8 Mbit/s down, 500 Kbit/s up) but I get the same sort of start-up time when I turn off the network on the iPod, which suggests to me that isn't it. Auto-sync is on. Do you have a 1st generation model, or the current model? I'm also running the sneaky peek builds; I know Ken has done some performance work, but as I started with the iPod after he'd already incorporated it, I don't have a feeling for the magnitude of the impact on iPod/iPhone performance.

Another thought -- do you typically quit OF before it has a chance to sync any changes you have made? I almost never have to wait for a sync when I start up the program.
 
Quote:
Originally Posted by Chris View Post
Has there been any thought given to:

(1) an auto-archive preference.
(2) allowing archiving to a webdav server.

Both of these would encourage me to actually use the archive feature.
Yes, we're definitely thinking about this; it frustrates me, too! I don't want to have to remember whether my archive is at home or work, I want my archive available everywhere my main database is, and I want to automatically synchronize any changes I make to my archive just like I do with my main database.

There are some UI questions to think through (do we just sync to the same location as we do the main database?), but fundamentally there isn't anything in the architecture to stop us from doing this: we've already designed the archive to track its changes for synchronization, just as we do for the main database.

So if we agree that that synchronizing the archive is a good idea and it's already been designed with syncing in mind, why don't we have a syncing archive already? Well, for the same reason that we don't yet have syncing perspectives: Rome wasn't built in a day! :) We're still working on OmniFocus, and I hope to get to that feature soon.
 
Hi Ken,

Preface: I own OF for Mac and iPhone, and am a happy camper. As a matter of fact I own almost all of the Omni apps, in their professional versions. :)

Re: Synchronization clients can lock down fewer transactions, allowing the database to compact more frequently.

Is there some sort of setting/toggle/etc for this? If so, where is it? I'm not seeing anything.

For me, opening up OF on the iPhone is a painful process (I use webDAV for synchronization). It takes several minutes. It almost always freezes the first time and needs to be 'force quit' and restarted. Anything that can make starting OF quicker would be greatly appreciated.

Thanks,
Mike
 
MRL - no toggle needed; it's an internal change we made in the way the app works.

Moving your post to the existing thread on minimizing app start time. Try the suggestions in this thread. :-)

Last edited by Brian; 2009-05-11 at 05:35 PM.. Reason: that -> this
 
This is my biggest complain about OmniFocus for the iPhone: launch speed. It takes much too much time (sometimes dozens of seconds) before OF has loaded the data (starting/opening document...).

I have 93 projects, 677 actions and 5 zip files. I removed all unnecessary clients, I only have my iPhone and portable mac. I also regularly archive on the Mac.

I regularly heard people saying they prefer other "lists/tasks" apps just because OF is too slow.

So please keep improving speed (I mean "launching speed"):
- cache as much info as you can
- first display the screen then load data (only needed data - lazy loading)
- reopen the app on the last screen (cache it's data)
- counters (number of items) - if that slows down the app - could be turned off in settings or could be cached (keep counter variables in the DB and update them when adding/removing items
- keep thinking!

I know background pocesses would help but in the mean time you can still do a lot more for speed and it will always be good for OF (even when bgnd processes are allowed by Apple)..,

Good luck and keep up the good work!

Last edited by vincentkeunen; 2009-07-24 at 12:16 AM..
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
Minimizing OmniFocus for iPhone's startup & sync time Brian OmniFocus Syncing 44 2013-07-16 06:44 AM
OmniFocus fails sync first time around, always have to Retry to get successful sync nathanw Other WebDAV 6 2012-10-19 06:08 PM
Long startup time HenricF OmniFocus for iPhone 4 2010-12-15 03:40 AM
Syncing iphone OmniFocus to iPhone's Calendar with Windows mikewilliams78 OmniFocus Syncing 2 2010-06-17 07:19 PM
Poll: Is OmniFocus in your iPhone's dock? jordanekay OmniFocus for iPhone 46 2008-09-21 01:22 AM


All times are GMT -8. The time now is 06:46 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.