Updating an app's help

  • With each update of our app, we typically change the help book. We're finding that the system is very poor at recognising this and caches old versions of the help which causes new stuff we add to be unavailable. While I can manually trash the help caches and force an update, this isn't something we can ask or expect of our users.

    Is there a supported way of forcing the help system to update or to discard its caches?

    --Graham
  • This works for me:

    killall helpd
    rm -rf ~/Library/Caches/com.apple.help*

    --
    Gleb Dolgich
    PixelEspresso
    http://www.pixelespressoapps.com

    On 13 Dec 2011, at 22:17, Graham Cox wrote:

    > With each update of our app, we typically change the help book. We're finding that the system is very poor at recognising this and caches old versions of the help which causes new stuff we add to be unavailable. While I can manually trash the help caches and force an update, this isn't something we can ask or expect of our users.
    >
    > Is there a supported way of forcing the help system to update or to discard its caches?
  • Thanks, but that's even worse to ask the user to do on every update.

    I'm looking either for a) some way of indicating to the help system that it needs to update the cached copy of our help or b) a way to force it to do so using some API.

    I'm following up a hint I received offline - looks like our help bundle is incomplete at the moment which could be part of the problem.

    --Graham

    On 14/12/2011, at 1:44 PM, Gleb Dolgich wrote:

    > This works for me:
    >
    > killall helpd
    > rm -rf ~/Library/Caches/com.apple.help*
    >
    > --
    > Gleb Dolgich
    > PixelEspresso
    > http://www.pixelespressoapps.com
    >
    > On 13 Dec 2011, at 22:17, Graham Cox wrote:
    >
    >> With each update of our app, we typically change the help book. We're finding that the system is very poor at recognising this and caches old versions of the help which causes new stuff we add to be unavailable. While I can manually trash the help caches and force an update, this isn't something we can ask or expect of our users.
    >>
    >> Is there a supported way of forcing the help system to update or to discard its caches?
    >
  • Ah, missed the whole "user" part. If you use a Snow Leo+ help bundle and increment its version for each update, perhaps Help Viewer is smart enough to recognise the update?

    On 14 Dec 2011, at 02:51, Graham Cox wrote:

    > Thanks, but that's even worse to ask the user to do on every update.
    >
    > I'm looking either for a) some way of indicating to the help system that it needs to update the cached copy of our help or b) a way to force it to do so using some API.
    >
    > I'm following up a hint I received offline - looks like our help bundle is incomplete at the moment which could be part of the problem.
    >
    > --Graham
    >
    >
    >
    > On 14/12/2011, at 1:44 PM, Gleb Dolgich wrote:
    >
    >> This works for me:
    >>
    >> killall helpd
    >> rm -rf ~/Library/Caches/com.apple.help*
    >>
    >> --
    >> Gleb Dolgich
    >> PixelEspresso
    >> http://www.pixelespressoapps.com
    >>
    >> On 13 Dec 2011, at 22:17, Graham Cox wrote:
    >>
    >>> With each update of our app, we typically change the help book. We're finding that the system is very poor at recognising this and caches old versions of the help which causes new stuff we add to be unavailable. While I can manually trash the help caches and force an update, this isn't something we can ask or expect of our users.
    >>>
    >>> Is there a supported way of forcing the help system to update or to discard its caches?
    >>
    >
  • On Dec 13, 2011, at 5:17 PM, Graham Cox wrote:

    > With each update of our app, we typically change the help book. We're finding that the system is very poor at recognising this and caches old versions of the help which causes new stuff we add to be unavailable. While I can manually trash the help caches and force an update, this isn't something we can ask or expect of our users.

    Search the archives, and you will discover that you are likely experiencing a well-known issue that has been around for a very long time. It typically only affects the developer, not your users. It is especially annoying to the developer if another, older version of the application is still on your computer, in the Applications folder or perhaps in the form of earlier build products that are still sitting around, because then trashing the help caches and forcing an update won't necessarily stop the system from using the old version of your Help folder in an older version of your application.

    When I am working on my Help folders, I routinely compress all older versions of the application into zip files for the duration, and I trash the Help caches before every test.

    The typical user trashes the old version of the application when they install the new version, and all is well.

    --

    Bill Cheeseman - <bill...>
  • On Wed, 14 Dec 2011 05:14:36 -0500, Bill Cheeseman <wjcheeseman...> said:
    > Search the archives, and you will discover that you are likely experiencing a well-known issue that has been around for a very long time. It typically only affects the developer, not your users. It is especially annoying to the developer if another, older version of the application is still on your computer, in the Applications folder or perhaps in the form of earlier build products that are still sitting around, because then trashing the help caches and forcing an update won't necessarily stop the system from using the old version of your Help folder in an older version of your application.

    And not just with help, either. I've been in situations where a developer was sending me new versions of an application several times a day, and it would sometimes happen that I would double-click a new version and an older version's code would run. (This resulted in some really strange conversations about the behavior of the application.) There's some underlying caching mechanism here. As you rightly say, the solution is to trash the old version *and empty the trash* before launching the new version. m.

    PS I've also quite often seen it happen that I'll update my code for an iOS app I'm developing and run it and an older version of the app will run, but this is for a different reason, I think.

    --
    matt neuburg, phd = <matt...>, <http://www.apeth.net/matt/>
    A fool + a tool + an autorelease pool = cool!
    Programming iOS 4!
    I've not seen Mac OS X fail to run an app I've double-clicked on, but
    it is notorious for grabbing seemly random old versions of plugins
    like Automator actions, quicklook plugins, Services from older apps
    that are still around -- sometimes giving precedence to apps on
    non-boot volumes (over one on the boot volume).

    It is especially an annoying mess for developers, who are more likely
    to have multiple versions lurking about.

    On Thu, Dec 15, 2011 at 7:28 PM, Matt Neuburg <matt...> wrote:
    > On Wed, 14 Dec 2011 05:14:36 -0500, Bill Cheeseman <wjcheeseman...> said:
    >> Search the archives, and you will discover that you are likely experiencing a well-known issue that has been around for a very long time. It typically only affects the developer, not your users. It is especially annoying to the developer if another, older version of the application is still on your computer, in the Applications folder or perhaps in the form of earlier build products that are still sitting around, because then trashing the help caches and forcing an update won't necessarily stop the system from using the old version of your Help folder in an older version of your application.
    >
    > And not just with help, either. I've been in situations where a developer was sending me new versions of an application several times a day, and it would sometimes happen that I would double-click a new version and an older version's code would run. (This resulted in some really strange conversations about the behavior of the application.) There's some underlying caching mechanism here. As you rightly say, the solution is to trash the old version *and empty the trash* before launching the new version. m.
    >
    > PS I've also quite often seen it happen that I'll update my code for an iOS app I'm developing and run it and an older version of the app will run, but this is for a different reason, I think.
    >
    > --
    > matt neuburg, phd = <matt...>, <http://www.apeth.net/matt/>
    > A fool + a tool + an autorelease pool = cool!
    > Programming iOS 4!
    > http://www.unmarked.com/
  • At least with quicklook there's qlmanage: "qlmanage -m" will show which copy of the plugin it's using. If it's using the wrong one delete it, do "qlmanage -r" to reload, and repeat until it finds the right one.

    Something like that for help would be nice. I don't test quicklook that often but our QA people hit the help issue frequently.

    ----- Original Message -----
    From: "Mark Munz" <unmarked...>
    To: "Matt Neuburg" <matt...>
    Cc: "Cocoa-Dev List" <cocoa-dev...>
    Sent: Thursday, December 15, 2011 8:28:55 PM
    Subject: Re: Updating an app's help

    I've not seen Mac OS X fail to run an app I've double-clicked on, but
    it is notorious for grabbing seemly random old versions of plugins
    like Automator actions, quicklook plugins, Services from older apps
    that are still around -- sometimes giving precedence to apps on
    non-boot volumes (over one on the boot volume).

    It is especially an annoying mess for developers, who are more likely
    to have multiple versions lurking about.

    On Thu, Dec 15, 2011 at 7:28 PM, Matt Neuburg <matt...> wrote:
    > On Wed, 14 Dec 2011 05:14:36 -0500, Bill Cheeseman <wjcheeseman...> said:
    >> Search the archives, and you will discover that you are likely experiencing a well-known issue that has been around for a very long time. It typically only affects the developer, not your users. It is especially annoying to the developer if another, older version of the application is still on your computer, in the Applications folder or perhaps in the form of earlier build products that are still sitting around, because then trashing the help caches and forcing an update won't necessarily stop the system from using the old version of your Help folder in an older version of your application.
    >
    > And not just with help, either. I've been in situations where a developer was sending me new versions of an application several times a day, and it would sometimes happen that I would double-click a new version and an older version's code would run. (This resulted in some really strange conversations about the behavior of the application.) There's some underlying caching mechanism here. As you rightly say, the solution is to trash the old version *and empty the trash* before launching the new version. m.
    >
    > PS I've also quite often seen it happen that I'll update my code for an iOS app I'm developing and run it and an older version of the app will run, but this is for a different reason, I think.
    >
    > --
    > matt neuburg, phd = <matt...>, <http://www.apeth.net/matt/>
    > A fool + a tool + an autorelease pool = cool!
    > Programming iOS 4!
    > http://www.unmarked.com/
  • On Dec 15, 2011, at 10:28 PM, Mark Munz wrote:

    > I've not seen Mac OS X fail to run an app I've double-clicked on, but
    > it is notorious for grabbing seemly random old versions of plugins
    > like Automator actions, quicklook plugins, Services from older apps
    > that are still around -- sometimes giving precedence to apps on
    > non-boot volumes (over one on the boot volume).
    >
    > It is especially an annoying mess for developers, who are more likely
    > to have multiple versions lurking about.

    Don’t forget document-application bindings. Double-click a file that belongs to application “Foo” when you have both Foo 1.0 and Foo 2.0 installed on your machine, and who knows which one you’ll get — but boy, does it ever love to pick things out of ~/Library/Mail and ~/Library/Mail Downloads.

    If Apple updated LaunchServices to have it look at the CFBundleVersion when multiple applications have the same bundle identifier and always pick the latest one, I’d be a happy man.

    Charles
  • On Lion you cannot run any application from the Trash folder. Simply moving old versions there should be enough.

    On Dec 15, 2011, at 9:28 PM, Matt Neuburg wrote:

    > On Wed, 14 Dec 2011 05:14:36 -0500, Bill Cheeseman <wjcheeseman...> said:
    >> Search the archives, and you will discover that you are likely experiencing a well-known issue that has been around for a very long time. It typically only affects the developer, not your users. It is especially annoying to the developer if another, older version of the application is still on your computer, in the Applications folder or perhaps in the form of earlier build products that are still sitting around, because then trashing the help caches and forcing an update won't necessarily stop the system from using the old version of your Help folder in an older version of your application.
    >
    > And not just with help, either. I've been in situations where a developer was sending me new versions of an application several times a day, and it would sometimes happen that I would double-click a new version and an older version's code would run. (This resulted in some really strange conversations about the behavior of the application.) There's some underlying caching mechanism here. As you rightly say, the solution is to trash the old version *and empty the trash* before launching the new version. m.
    >
    > PS I've also quite often seen it happen that I'll update my code for an iOS app I'm developing and run it and an older version of the app will run, but this is for a different reason, I think.
    >
    > -
  • On Dec 16, 2011, at 1:36 AM, Charles Srstka <cocoadev...> wrote:

    > On Dec 15, 2011, at 10:28 PM, Mark Munz wrote:
    >
    >> I've not seen Mac OS X fail to run an app I've double-clicked on, but
    >> it is notorious for grabbing seemly random old versions of plugins
    >> like Automator actions, quicklook plugins, Services from older apps
    >> that are still around -- sometimes giving precedence to apps on
    >> non-boot volumes (over one on the boot volume).
    >>
    >> It is especially an annoying mess for developers, who are more likely
    >> to have multiple versions lurking about.
    >
    > Don’t forget document-application bindings. Double-click a file that belongs to application “Foo” when you have both Foo 1.0 and Foo 2.0 installed on your machine, and who knows which one you’ll get — but boy, does it ever love to pick things out of ~/Library/Mail and ~/Library/Mail Downloads.
    >
    > If Apple updated LaunchServices to have it look at the CFBundleVersion when multiple applications have the same bundle identifier and always pick the latest one, I’d be a happy man.

    I believe this is what it's supposed to be doing. Part of it might be a LaunchServices bug, but another part of it might be that your CFBundleVersionNumbers don't conform to the spec that LS is using: http://lists.apple.com/archives/carbon-dev/2006/jun/msg00139.html

    Our build system currently produces bundle version numbers of the form NN.0.SVNREV for bundles built from trunk. This doesn't conform to the format Christopher posted. Bundles built from branches have the form NN.N.0.SVNREV, which _does_ conform. I am curious if that is the reason LS prefers to launch old versions of my apps rather than the version under development.

    --Kyle Sluder
previous month december 2011 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Go to today