ons?
>
> What are people's thoughts?
>
> I've tried searching online and the only problems/solutions I can see are all
> related to people's progress bars not updating properly because they're
> blocking the main thread etc. I can't see anything related to be
On Jul 28, 2017, at 14:16 , Mark Allan wrote:
>
> Reducing the frequency of NSXPC messages was a secondary goal to figuring out
> how often the main app ought to be updating the UI.
I’d be interested in knowing why you didn’t say that the other way round.
Surely reducing the frequency of the X
Many thanks for all the responses. In terms of what I'm doing, the NSTimer
with 0.1 second granularity sounds like the best fit.
> On 28 Jul 2017, at 7:26 pm, Charles Srstka wrote:
>
> If you’re using Swift
Still on Objective-C. Thanks though, I'll keep that bookmarked for when I
venture i
e tried searching online and the only problems/solutions I can see are all
> related to people's progress bars not updating properly because they're
> blocking the main thread etc. I can't see anything related to best practice.
>
> Many thanks
> Mark
>
> PS
On Jul 28, 2017, at 08:57 , Mark Allan wrote:
>
> I have an app with a helper tool that performs some lengthy process in a loop
> and reports progress to the user. It works out how many iterations of the
> loop will be needed, sets the progressbar.maxValue, and then increments the
> progress
On 28 Jul 2017, at 16:57, Mark Allan wrote:
>
> I'm wondering if anyone has any thoughts about or links to best practices
> when using determinate NSProgressIndicators.
[snip]
> I'm debating doing it with an NSTimer firing every second, but wondered if
> anyone had any other suggestions?
I’d
> Am 28.07.2017 um 17:57 schrieb Mark Allan :
>
> Setting the max value to 100 and only updating 100 times (i.e. as a
> percentage) seems too infrequent because the loop can iterate more than a
> million times.
Just keep track of the time of the last update and do it every 0.1 seconds or
so.
y problems/solutions I can see are all
related to people's progress bars not updating properly because they're
blocking the main thread etc. I can't see anything related to best practice.
Many thanks
Mark
PS. It could be that this is a case of p
I have a UIScrollView scrolled to the bottom of content - so the content
bottom is at the bottom of the view - in a compact environment.
When the view rotates to regular, the contentOffset is too large - so
the bottom of the content appears in the middle of the view.
Without hard coding nav b
On Aug 16, 2015, at 11:13 AM, Kevin Meaney wrote:
> I’ve annotated the public methods of the API of a framework and though I
> haven’t yet I will annotate internal methods and functions as well.
>
> I found a small number of issues where my thinking had not been clear, and
> that having to sto
> On Aug 8, 2015, at 1:15 PM, Seth Willits wrote:
>
> Let's stipulate that _Nullable and _Nonnull are great to have because they
> can catch bugs and express API intent better than before, so we want them.
> The question is where to put them?
>
>
> _Nullable and _Nonnull make perfect sense t
I’ve annotated the public methods of the API of a framework and though I
haven’t yet I will annotate internal methods and functions as well.
I found a small number of issues where my thinking had not been clear, and that
having to stop and consider what was intended when annotating the public AP
On Aug 16, 2015, at 09:10 , Seth Willits wrote:
>
> Really? This list has no opinions? That's hard to imagine :-)
Well, I do, but I didn’t post it because I didn’t think you’d like it.
I don’t think it’s worth annotating private methods at all (in general — I’m
sure there are specific cases wh
Really? This list has no opinions? That's hard to imagine :-)
--
Seth Willits
> On Aug 8, 2015, at 1:15 PM, Seth Willits wrote:
>
> Let's stipulate that _Nullable and _Nonnull are great to have because they
> can catch bugs and express API intent better than before, so we want them.
> The
Let's stipulate that _Nullable and _Nonnull are great to have because they can
catch bugs and express API intent better than before, so we want them. The
question is where to put them?
_Nullable and _Nonnull make perfect sense to specify in the @interface. Since
those annotations existing in t
> On Sep 2, 2014, at 4:18 PM, Quincey Morris
> wrote:
>
> Then is there any downside to letting it appear beside the final location?
It's not the location that bugs me, so much as that it never gets cleaned up.
So the parent directory starts accumulating more and more of these empty
"(Docum
On Tue, Sep 2, 2014, at 06:10 PM, Jens Alfke wrote:
>
> > On Sep 2, 2014, at 4:05 PM, Quincey Morris
> > wrote:
> >
> > I get a URL to a new folder in the private (secure) temporary directory,
> > and *not* in the parent of ‘importURL’. I don’t know why you’re seeing
> > something different.
On Sep 2, 2014, at 16:10 , Jens Alfke wrote:
> This is on iOS.
Then is there any downside to letting it appear beside the final location?
Where does an app like Pages create its autosaves? (AFAIK, autosave uses this
same API for its temp folder.)
IIRC, in iOS the recommendation is to put docu
> On Sep 2, 2014, at 4:05 PM, Quincey Morris
> wrote:
>
> I get a URL to a new folder in the private (secure) temporary directory, and
> *not* in the parent of ‘importURL’. I don’t know why you’re seeing something
> different.
This is on iOS. (On Mac OS I do see the file appear in the tempor
On Sep 2, 2014, at 09:47 , Jens Alfke wrote:
> So far I've been using NSItemReplacementDirectory, but this has a couple of
> problems:
> (1) It creates a new visible directory right next to the permanent location,
> called "(A Document being saved by $APP") where $APP is the app name.
FWIW, th
Maybe you could:
- write the temp path into a file in Application Support or someplace where you
can read it at launch
- make a temp invisible file at that temp path in the actual destination folder
- rename the temp invisible file and make it visible
- clear the temp path where you'd written it
> On Sep 2, 2014, at 10:45 AM, Kyle Sluder wrote:
>
> .TemporaryItems doesn't get cleaned up automatically AFAIK, so I don't
> think you'll gain anything by trying to use it.
On my system right now there's nothing in it older than 2 days or so, so I
suspect it does get cleaned up (at least on
: "Cocoa-dev@lists.apple.com dev"
Date: Tuesday, September 2, 2014 9:47:37 AM GMT-0700
Subject: Best practice for creating a temporary file
I'm downloading data that will eventually be saved as a file in a specific
directory. During the download I write the data to a temporary file s
On Tue, Sep 2, 2014, at 11:47 AM, Jens Alfke wrote:
>
> It looks as though there _is_ a per-volume temporary-items directory,
> because on my non-boot partition I see a top-level invisible directory
> called ".TemporaryItems" with a subfolder for each user-ID. But how do I
> find it programmatical
I'm downloading data that will eventually be saved as a file in a specific
directory. During the download I write the data to a temporary file since it
can be arbitrarily large; then on completion I move the temporary file to its
final location. So I need to locate a temporary-files directory th
On Jan 4, 2014, at 3:58 PM, Alex Hall wrote:
> //store a keystroke
> NSUInteger key=[event keyCode]+[event modifierFlags];
This isn't safe. The documented device-independent modifier flags are all in
the high 16 bits of a 32-bit value, but there are other flags in the other
bits. At the very
On Jan 4, 2014, at 2:14 PM, Steve Mills wrote:
> On Jan 4, 2014, at 10:13:46, Alex Hall wrote:
>
>> Yes, I can do it, but it seems like there must be a more efficient way than
>> or-ing every combination of those five masks with the modifier flags each
>> keypress contains. I can't be the fi
On 2014 Jan 04, at 11:14, Steve Mills wrote:
> There ya go, 2 shorts make UInt32.
Yes, except unless you’re doing this for fun, I wouldn’t get down to the bit
level because this code, which is somewhat tedious (conversions between Carbon
and Cocoa key codes come to mind), has already been wri
On Jan 4, 2014, at 10:13:46, Alex Hall wrote:
> As I build the map and the rest of the game engine, I'll need to detect and
> match up keystrokes. I want the user to be able to define these if they want
> to, plus I know there has to be a better way to store them than hard-coded in
> a bunch o
Hello list,
I'm happy to say my audio game is now working. The game itself is not written
yet, but the audio menu is doing well - I can navigate it with the arrow keys
and the proper selector is called when I press enter. Thanks again for all your
help thus far.
As I build the map and the rest
On Oct 16, 2013, at 3:39 PM, Charles Srstka wrote:
> 3. (This is the one I'd recommend) Instead of using NSNib, make a subclass of
> NSWindowController (if your nib defines a window) or NSViewController (if
> your nib defines a view). Then use either -[NSWindowController
> initWithWindowNibNam
On Oct 16, 2013, at 16:39:04, Charles Srstka wrote:
> Aha, that definitely explains the leaks you've been getting. The trouble with
> instantiateWithOwner:, and the reason it's been deprecated, is because it
> doesn't follow the standard Cocoa memory management rules. Specifically, it
> retain
On Oct 16, 2013, at 4:20 PM, Steve Mills wrote:
> On Oct 16, 2013, at 12:56:00, Andy Lee wrote:
>
>> As for the creeping memory footprint, maybe try Heapshot Analysis to see
>> what objects are being created during particular intervals?
>
> Aha! Thanks, I didn't know about this very helpful
On Oct 16, 2013, at 12:56:00, Andy Lee wrote:
> As for the creeping memory footprint, maybe try Heapshot Analysis to see what
> objects are being created during particular intervals?
Aha! Thanks, I didn't know about this very helpful debugging aid yet. I was
getting about a meg worth of junk e
Hi,
Out of interest, have you tried doing this:
- (NSMenuItem*)itemWithTag:(NSInteger)tag searchSubmenus:(BOOL)searchSubmenus
depthFirst:(BOOL)depthFirst
{
NSMenuItem* item; //*
NSArray*myArray;//*
NSMenuItem* subi
On 16 Oct 2013, at 18:57, Steve Mills wrote:
> So at this point, let's finish this thread by going back to my original
> question. Is it OK to use the private instance variable _itemArray in NSMenu
> since the methods we've added are *extensions* of NSMenu and not a subclass?
> They simply iter
On Oct 16, 2013, at 2:09 PM, Steve Mills wrote:
> On Oct 16, 2013, at 12:45:49, Andy Lee wrote:
>
>> I still don't see what mutability has to do with it, but that's a side issue.
>
> The mutability doesn't matter. I'm just emphasizing that the internal array
> is mutable and this is returnin
On 16 Oct 2013, at 11:57 AM, Steve Mills wrote:
> So at this point, let's finish this thread by going back to my original
> question. Is it OK to use the private instance variable _itemArray in NSMenu
> since the methods we've added are *extensions* of NSMenu and not a subclass?
> They simply
On Oct 16, 2013, at 12:45:49, Andy Lee wrote:
> I still don't see what mutability has to do with it, but that's a side issue.
The mutability doesn't matter. I'm just emphasizing that the internal array is
mutable and this is returning a COPY of that array (which happens to be
immutable).
> I
On Oct 16, 2013, at 1:38 PM, Charles Srstka wrote:
> On Oct 16, 2013, at 11:57 AM, Steve Mills wrote:
>
>> So at this point, let's finish this thread by going back to my original
>> question. Is it OK to use the private instance variable _itemArray in NSMenu
>> since the methods we've added ar
On Wed, 16 Oct 2013 01:18:18 -0700, Greg Parker said:
>You can call +[NSAutoreleasePool showPools] from the debugger to log the
>autorelease pool stack to the console (check both the debugger console
On Wed, 16 Oct 2013 01:25:45 -0700, Greg Parker said:
>those OS versions you can run with enviro
On Oct 16, 2013, at 12:57 PM, Steve Mills wrote:
> So at this point, let's finish this thread by going back to my original
> question. Is it OK to use the private instance variable _itemArray in NSMenu
> since the methods we've added are *extensions* of NSMenu and not a subclass?
> They simply
On Oct 16, 2013, at 11:57 AM, Steve Mills wrote:
> So at this point, let's finish this thread by going back to my original
> question. Is it OK to use the private instance variable _itemArray in NSMenu
> since the methods we've added are *extensions* of NSMenu and not a subclass?
I wouldn't. I
On Oct 16, 2013, at 10:08:03, Ken Thomases wrote:
> Released to the point of being deallocated? Deallocation would also be
> indicated in the history.
# Address CategoryEvent Type RefCt Timestamp Size
Responsible Library Responsible Caller
0 0x7eb9c160
On Oct 16, 2013, at 9:38 AM, Steve Mills wrote:
> On Oct 16, 2013, at 00:28:17, Ken Thomases wrote:
>
>> Regarding the general issue of the mystery objects that are still alive,
>> there's little point in speculating. Look at the object's history in the
>> Allocations instrument to see not on
On Oct 16, 2013, at 00:28:17, Ken Thomases wrote:
> Regarding the general issue of the mystery objects that are still alive,
> there's little point in speculating. Look at the object's history in the
> Allocations instrument to see not only where it was allocated but all
> retains, releases,
On Oct 16, 2013, at 03:25:45, Greg Parker wrote:
> On sufficiently-recent OS versions, the runtime will silently push an
> autorelease pool if you autorelease without one. This can lead to
> unrecognized leaks if this happens on a long-lived thread. On some of those
> OS versions you can run w
On Oct 16, 2013, at 02:31:16, Charles Srstka wrote:
> Just out of curiosity, what kind of run loop are you running in? I ask
> because the older Finale 2012 appears to use a Carbon run loop while using
> some Cocoa elements here and there. Is this still the case, or have you
> switched to a Co
On Oct 15, 2013, at 23:54:56, Jens Alfke wrote:
> Then they’re not strictly speaking leaks — something is still pointing to
> them (and likely holding references to them.)
>
> It might be an autorelease pool that isn’t getting drained, but the stack you
> showed is inside a call to -[NSMenu up
On Oct 16, 2013, at 12:31 AM, Charles Srstka wrote:
> I ask because if you're not using NSApplication's run loop, you won't get an
> automatic release pool, which would explain what you were seeing.
On sufficiently-recent OS versions, the runtime will silently push an
autorelease pool if you a
On Oct 15, 2013, at 9:13 PM, Steve Mills wrote:
> Here's a typical stack for most of the calls to itemArray:
>
> 0 libsystem_c.dylib calloc
> 1 libobjc.A.dylib _class_createInstanceFromZone
> 2 libobjc.A.dylib _class_createInstance
> 3 CoreFoundation __CFAllocateObject2
> 4 CoreFoundati
On Oct 15, 2013, at 11:13 PM, Steve Mills wrote:
> On Oct 15, 2013, at 17:22:26, Graham Cox
> wrote:
>
>> OK, so if that's the case, I'm interested in knowing whether each call to
>> -itemArray returns the same object or a different one each time. If it's
>> different, then it's either a copy
On Oct 15, 2013, at 11:54 PM, Jens Alfke wrote:
> Is it possible your code has called [NSAutoreleasePool new] someplace but not
> called -release on it when it’s done? That would have exactly this kind of
> effect — every autoreleased object would be stuck in memory but not shown as
> a leak.
On Oct 15, 2013, at 9:13 PM, Steve Mills wrote:
> This is running our release target. Zombies is off. Am I just not reading
> this data correctly? These do NOT appear as leaks in the Leaks instrument,
> only as allocations in the Allocations instrument. If I run this particular
> code over an
On Oct 15, 2013, at 17:22:26, Graham Cox
wrote:
> OK, so if that's the case, I'm interested in knowing whether each call to
> -itemArray returns the same object or a different one each time. If it's
> different, then it's either a copy of some internal array or something built
> on the fly.
On Oct 15, 2013, at 9:08 PM, Steve Mills wrote:
> I haven't retained or released anything. I'm simply calling itemArray.
What items are in the menu? How did they get there?
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
_
On Oct 15, 2013, at 20:23:22, Scott Ribe
wrote:
> On Oct 15, 2013, at 4:10 PM, "Mills, Steve" wrote:
>
>> No, it's the itemArray. Ignore the code you can't see in the loop. It's
>> simply asking each item for its tag.
>
> But you could have over-retained them or under-released them somewhere
On Oct 15, 2013, at 4:10 PM, "Mills, Steve" wrote:
> No, it's the itemArray. Ignore the code you can't see in the loop. It's
> simply asking each item for its tag.
But you could have over-retained them or under-released them somewhere else,
and I think that was Graham's point.
--
Scott Ribe
On Oct 15, 2013, at 6:22 PM, Graham Cox wrote:
>
> On 15/10/2013, at 11:10 PM, "Mills, Steve" wrote:
>
>> No, it's the itemArray. Ignore the code you can't see in the loop. It's
>> simply asking each item for its tag.
>
>
> OK, so if that's the case, I'm interested in knowing whether each
On Oct 15, 2013, at 2:39 PM, Steve Mills wrote:
> I don't think this is the case. I was seeing hundreds of still-alive
> allocated objects that came from the copied itemArray. I could clearly see a
> pattern in the Allocations sampling of Instruments of these objects, with the
> pattern repeati
On 10/15/2013 2:39 PM, "Steve Mills" wrote:
>I don't think this is the case. I was seeing hundreds of still-alive
>allocated objects that came from the copied itemArray.
Ah, so within Instruments, are you looking at the objects that are
allocated or the objects that are leaking? Those are two
On 15/10/2013, at 11:10 PM, "Mills, Steve" wrote:
> No, it's the itemArray. Ignore the code you can't see in the loop. It's
> simply asking each item for its tag.
OK, so if that's the case, I'm interested in knowing whether each call to
-itemArray returns the same object or a different one e
On Oct 15, 2013, at 17:05, "Graham Cox"
mailto:graham@bigpond.com>> wrote:
On 15/10/2013, at 10:39 PM, Steve Mills
mailto:smi...@makemusic.com>> wrote:
I was seeing hundreds of still-alive allocated objects that came from the
copied itemArray
OK, so the objects *IN* the array are leaking
On 15/10/2013, at 10:39 PM, Steve Mills wrote:
> I was seeing hundreds of still-alive allocated objects that came from the
> copied itemArray
OK, so the objects *IN* the array are leaking, not the array itself, as you
initially stated?
That's a totally different, probably unrelated issue. Pr
On Oct 15, 2013, at 16:05:06, Andy Lee wrote:
> Out of curiosity, when you say you have "extended" NSMenu, do you mean you've
> subclassed it? That is what I would infer from your mention of class
> extensions. Is there some reason you don't add a category instead? I wonder
> because you on
On Oct 15, 2013, at 15:35:32, Kyle Sluder
wrote:
> They shouldn't be leaking. You're correct that -itemArray doesn't follow
> the naming convention of an object-creation method (new, alloc, copy,
> etc.), so you should not assume a +1 owning reference.
Thanks for confirming that.
> Are you per
On Oct 15, 2013, at 4:30 PM, Steve Mills wrote:
> On Oct 15, 2013, at 14:50:51, Steve Mills wrote:
>
>> NSArray*items = [self itemArray];
>>
>> for(NSMenuItem* item in items)
>> blah;
>>
>> [items release];
>
>
> Ah, this one won't work (
On Oct 15, 2013, at 5:05 PM, Andy Lee wrote:
> Then instead of [self itemArray] you could use [self nonLeakingItemArray].
If you are indeed subclassing, even better would be to override itemArray to
return [self nonLeakingItemArray]. Then you can use [self itemArray]
everywhere else and the co
On Oct 15, 2013, at 3:50 PM, Steve Mills wrote:
> We have extended NSMenu so we could add some other methods. Many of the
> methods iterate over the itemArray like so:
>
> for(NSMenuItem* item in [self itemArray])
>
> Instruments shows that we're leaking NSArrays created when itemArray re
On Tue, Oct 15, 2013, at 12:50 PM, Steve Mills wrote:
> We have extended NSMenu so we could add some other methods. Many of the
> methods iterate over the itemArray like so:
>
> for(NSMenuItem* item in [self itemArray])
>
> Instruments shows that we're leaking NSArrays created when itemArra
On Oct 15, 2013, at 12:50 PM, Steve Mills wrote:
> Instruments shows that we're leaking NSArrays created when itemArray returns.
> I assume whoever wrote these methods was assuming that itemArray would simply
> return the internal NSArray and not make a copy.
You don’t need to release the ret
On Oct 15, 2013, at 14:50:51, Steve Mills wrote:
> NSArray*items = [self itemArray];
>
> for(NSMenuItem* item in items)
> blah;
>
> [items release];
Ah, this one won't work (I didn't try it before when I wrote my original
message) b
We have extended NSMenu so we could add some other methods. Many of the methods
iterate over the itemArray like so:
for(NSMenuItem* item in [self itemArray])
Instruments shows that we're leaking NSArrays created when itemArray returns. I
assume whoever wrote these methods was assuming t
at would be
considered best practice.
> If you have the space, combine the two: Put a button in the instructions that
> creates an example item. But I'd still suggest that you *probably* should
> have the same buttons available in both orientations, even if it's in a
> pop
On 20.09.2012, at 08:49, Richard Altenburg (Brainchild)
wrote:
> The Add button not being there in portrait mode on iPad is how the default
> Master-Detail template works.
You're letting a template file made by a programmer that illustrates how to
code decide what features your user interface
Op 19 sep. 2012, om 22:31 heeft Uli Kusterer het
volgende geschreven:
> Is the item actually useful to the user beyond being there? Or would the user
> have to delete the item and create a sensible one to actually use your app?
The item is like a demo of what an item could look like, and the u
I might do both, although I can not do a "tap here" instruction if the Add
button is not visible at launch. Have to create another way for that initial
item to become alive.
Thanks for your thoughts.
[[[Brainchild alloc] initWithName:@"Richard Altenburg"] saysBestRegards];
Op 19 sep. 2012, om
Hi,
I have tabbar based audio streaming application. I want to receive the
remote control event when app is in any tab when it is in background. So I have
implemented beginReceivingRemoteControlEvents and endReceiveRemoteControlEvents
in each view controllers viewWillAppear and viewWillDisapp
On 19.09.2012, at 20:30, Richard Altenburg (Brainchild)
wrote:
> Is it considered good practice to create an initial item on start-up (only
> when there is no user created item already) and programmatically select that
> item in the table view and go into its detail view immediately? That way t
Seed data is always a good idea. A “tap here to make a new item” approach
would also work in some cases.
Best,
Eve
On Sep 19, 2012, at 11:30 AM, "Richard Altenburg (Brainchild)"
wrote:
> I am creating a master-detail app for both iPad and iPhone families of
> devices. For the iPad I use a s
I am creating a master-detail app for both iPad and iPhone families of devices.
For the iPad I use a split view controller and for the iPhone I use the
standard drill-down interface (a table view when selected pushes the detail
view onto the screen).
Now it feels kind of awkward when a user fir
On Jun 20, 2012, at 11:32 PM, Michael de Haan wrote:
> Is the approach therefore to create the bindings to the databases, as well as
> the searchField in code ( as opposed to IB)?
You can do that. It's not hard to set and remove bindings in code.
Another possibility is to create your own clas
Thanks to both of you.
Much appreciated.
On Jun 20, 2012, at 11:48 PM, Scott Ribe wrote:
> On Jun 20, 2012, at 11:00 PM, Michael de Haan wrote:
>
>> I thought perhaps of setting up 2 tableViews/searchFields and simply
>> toggling (hide/show) between the 2 databases.
>
> I think that's a fine al
On Jun 20, 2012, at 11:00 PM, Michael de Haan wrote:
> I thought perhaps of setting up 2 tableViews/searchFields and simply toggling
> (hide/show) between the 2 databases.
I think that's a fine alternative: simplest coding, uses more memory, whether
the difference is important to your app or no
On Jun 20, 2012, at 11:26 PM, Jens Alfke wrote:
>
> On Jun 20, 2012, at 11:00 PM, Michael de Haan wrote:
>
>> I would like to be able to "toggle" between the 2 databases using the same
>> interface( i.e. the same tableView and searchField)(The tableView in one
>> would need an extra column).
On Jun 20, 2012, at 11:00 PM, Michael de Haan wrote:
> I would like to be able to "toggle" between the 2 databases using the same
> interface( i.e. the same tableView and searchField)(The tableView in one
> would need an extra column). I thought perhaps of setting up 2
> tableViews/searchField
At work, we use 2 large totally separate databases to look up codes needed for
coding procedures.
I have written a simple app to present the data, using bindings. Implemented a
search-field (binding based) and all works well.
My question is one of an approach. (There is a paucity for this type of
yer transforms to
scale/rotate images.
What is the best practice for this? Drawing with Core Graphics or
using NSViews? Or using CALayers? Why?
I have received some input to my StackOverflow question already as
well:
http://stackoverflow.com/questions/10621858/best-practice-for-laying-out-images
On Nov 15, 2011, at 7:17 PM, ico wrote:
> So what is the best practice to place these function? Simply write them as
> a C function or implement them in a common class and make them static?
Either way is OK, and you can find several examples of either technique in
Apple’s APIs — l
at it should not belong to any class, it is just a common task that many
classes will use them.
So what is the best practice to place these function? Simply write them as
a C function or implement them in a common class and make them static?
Thanks.
--
==
Life isn&#x
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/6/11 10:51 PM, Amy Gibbs wrote:
> After the announcements about iCloud, should I just wait a while and
> I'll be able to build this in 'for free' (there will be a cocoa way to
> do this)?
While the iCloud announcement was obviously public, all th
After the announcements about iCloud, should I just wait a while and
I'll be able to build this in 'for free' (there will be a cocoa way to
do this)?
On 3 Jun 2011, at 9:29PM, Evadne Wu wrote:
As for the SQLite file, I am never sure if Core Data’s OS X
implementation and iOS implementation
On Jun 3, 2011, at 1:29 PM, Evadne Wu wrote:
> As for the SQLite file, I am never sure if Core Data’s OS X implementation
> and iOS implementation share the same format and will continue to be so
SQLite’s file format is 100% consistent cross-platform. And I have no reason to
think the same’s n
As for the SQLite file, I am never sure if Core Data’s OS X implementation and
iOS implementation share the same format and will continue to be so, and it is
surely a very strong and valid idea to just use an intermediate format you
control, I’ve been bouncing them across OS X & iOS with no prob
Thanks
Sounds like dropbox would be a good fit, I'll download the ask and give it a go.
My current mac app stores the data in a sqllite file that I'm hoping to just
sync with dropbox. However it does currently also store images in a directory
and just store the paths as string attributes. Not s
On Fri, Jun 3, 2011 at 2:48 PM, Evadne Wu wrote:
> Dropbox sync is good for a pile of files, but no more than that. Let’s
> rebound the requirements:
>
> * there’s a single user Core Data app
> * want an iPad version of the app
> * the two versions will sync up
>
> Given the requirements, and ad
Dropbox sync is good for a pile of files, but no more than that. Let’s rebound
the requirements:
* there’s a single user Core Data app
* want an iPad version of the app
* the two versions will sync up
Given the requirements, and add the fact that I’m pretty sure that Dropbox
would keep conflic
On Jun 3, 2011, at 11:04 AM, Amy Heavey wrote:
> I've got a fairly basic core data app that I've written for personal use on
> my iMac. I'd like to have an iPad version as it would be very useful to have
> whilst I was mobile. (It's basically a customer/product database).
>
> Is there a best w
Could indeed be easiest solution ;)
You could also look at how you serialize or save data for export / import
between two environments.
Just have it custom save out to a standard plist format or a simple xml schema.
Then you can decouple that from the CoreData versioning and differences.
Internall
Thanks, It's an app for just me really. I just prefer to work on a
desktop mac when I'm in the house, and I can't carry my iMac with
me :) I do find typing much easier on an actual keyboard. Maybe I
should just get a keyboard for the iPad?
Many Thanks
Amy
On 3 Jun 2011, at 7:11PM, John
1 - 100 of 193 matches
Mail list logo
