On May 14, 2012, at 8:43 AM, Ken Thomases wrote:
> On May 14, 2012, at 8:52 AM, Glenn L. Austin wrote:
>
>> Read up on Grand Central Dispatch. It can manage pretty much all of the
>> hard work of parallelizing code, including replacing synchronization
>> primitives like Mutexes and CriticalReg
I'm parsing a large XML file using NSXMLParser (OS X) and part of the
nested structure is similar to this:
...
...
Home
123-555-1234
Work
345-555-6612
Mobile
222-555-8901
...
...
In advance I don't know how many phonenumbers there will be, there could be
none, or more
Was just wondering if there are any techniques to speed up the launching of iOS
apps.
Back in the Director day, I would create a shell executable that would launch
rather quickly and present a splash screen, then an animation that indicated to
the user that the test of the application was loadi
"Lazy loading" is the usual answer. Don't load a resource until the user needs
it.
View controllers are built this way. "viewDidLoad" (or loadView if you prefer)
should summon the resources and build the view.
Look around for other opportunities to delay initialization.
David
On May 15, 20
In my experience, this is usually localized to whatever you are doing in
applicationDidFinishLaunching and the complexity of the main nib that is being
loaded (and it's associated data, like graphics). Usually, getting your main
nib down to just what you need and loading the rest later goes a lo
Have you turned on "Multitasking Gestures" in the iPad General Settings?
D
On May 14, 2012, at 9:26 PM, Gerriet M. Denkmann wrote:
> I have an app which can be pinched and zoomed on an iPhone and on the iPhone
> Simulator.
>
> But it can not be zoomed or pinched on iPad or iPad Simulator.
>
On 15 May 2012, at 10:05 AM, Alex Zavatone wrote:
> Was just wondering if there are any techniques to speed up the launching of
> iOS apps.
>
> Back in the Director day, I would create a shell executable that would launch
> rather quickly and present a splash screen, then an animation that indi
Very enlightening Fritz. Thanks.
One approach I took on purpose was to use a synchronous load of a JSON data set
on startup.
I didn't want to display the main screen (TVC), until the main data had loaded
(a 4 KB data set) and serialized.
I'm wondering if with a larger data set, the approach
Responses below.
(Sent from my iPad.)
--
Conrad Shultz
On May 15, 2012, at 9:48, Alex Zavatone wrote:
> Very enlightening Fritz. Thanks.
>
> One approach I took on purpose was to use a synchronous load of a JSON data
> set on startup.
>
Given your statement below I interpret this to mean
On May 15, 2012, at 9:48 AM, Alex Zavatone wrote:
> I didn't want to display the main screen (TVC), until the main data had
> loaded (a 4 KB data set) and serialized.
> I'm wondering if with a larger data set, the approach should be to have the
> first scene use the same graphic as the launch s
On 15 May 2012, at 11:48 AM, Alex Zavatone wrote:
> async http load (through GDC or which preferred method?)
Until proven otherwise, Grand Central Dispatch is a bad choice for network
operations. Look at the documentation for NSURLConnection (and the URL Loading
System Programming Guide) for an
On May 15, 2012, at 1:16 PM, Conrad Shultz wrote:
> Responses below.
>
> (Sent from my iPad.)
>
> --
> Conrad Shultz
>
> On May 15, 2012, at 9:48, Alex Zavatone wrote:
>
>> Very enlightening Fritz. Thanks.
>>
>> One approach I took on purpose was to use a synchronous load of a JSON data
On May 15, 2012, at 11:18 AM, Alex Zavatone wrote:
> Yes, and I've tested it and we haven't had a problem with this. I trust your
> advice, yet all I can see is that if the data transmission fails mid 4KB data
> transfer, it would hang. In the case where the URL is invalid or
> unreachable, w
On 5/15/12 11:18 AM, Alex Zavatone wrote:
> Yes, and I've tested it and we haven't had a problem with this. I
> trust your advice, yet all I can see is that if the data transmission
> fails mid 4KB data transfer, it would hang. In the case where the
> URL is invalid or unreachable, we have a dict
- Zav
On May 15, 2012, at 10:44 AM, Jens Alfke wrote:
On May 15, 2012, at 9:48 AM, Alex Zavatone wrote:
I didn't want to display the main screen (TVC), until the main data had loaded
(a 4 KB data set) and serialized.
I'm wondering if with a larger data set, the approach should be to have th
OK. I've got one item to discuss with you, the splash/launch screen.
This is why I like it.
Right after clicking on an app's icon, the splash screen/launch screen shows
that the device has indeed paid attention to you and responded in the manner
you expected, namely, the application has launc
On May 15, 2012, at 11:18 AM, Alex Zavatone wrote:
> Yes, and I've tested it and we haven't had a problem with this.
But I thought you said you were trying to speed up launch time? Isn’t that the
impetus for this thread? And we’re pointing out that waiting for a network
request adds a lot of
On May 15, 2012, at 3:15 PM, Alex Zavatone wrote:
> OK. I've got one item to discuss with you, the splash/launch screen.
>
> This is why I like it.
>
> Right after clicking on an app's icon, the splash screen/launch screen shows
> that the device has indeed paid attention to you and responded
On May 15, 2012, at 1:15 PM, Alex Zavatone wrote:
> Right after clicking on an app's icon, the splash screen/launch screen shows
> that the device has indeed paid attention to you and responded in the manner
> you expected, namely, the application has launched and is proceeding to load.
> I can
On May 15, 2012, at 12:22 PM, Conrad Shultz
wrote:
I'm doing it because it's simply lame to display an empty TVC and
then have it fill in as content appears like an HTML page.
I don't know what you mean by "lame." That guidance is because it
*appears* to the user to be faster when you displ
On May 15, 2012, at 1:57 PM, Alex Zavatone wrote:
>
> But that's the point, I'm never going to display an empty TVC.
Yes you are, because best practice says you're going to let your app finish
launching while you load your data in the background. Or else prepare for
people to uninstall your
On May 15, 2012, at 01:22 PM, Jens Alfke wrote:
On May 15, 2012, at 11:18 AM, Alex Zavatone wrote:
Yes, and I've tested it and we haven't had a problem with this.
But I thought you said you were trying to speed up launch time? Isn’t that the
impetus for this thread? And we’re pointing out
On May 15, 2012, at 12:56 PM, Alex Zavatone wrote:
> We are caching (saving in a pList) the data from the previous launch. It
> falls through and uses the previously saved data if we can't get to the
> internet. Now, what I'm unclear on at this point (I've never truly truly
> trusted some sy
- Zav
On May 15, 2012, at 01:32 PM, glenn andreas wrote:
Since the data and scroll position of the first screen is variable, I don't see how I can display a screen
that is not "splash screen like". I've got no idea why someone would display an about window when
an app launches. Since I'm d
- Zav
On May 15, 2012, at 01:35 PM, Jens Alfke wrote:
On May 15, 2012, at 1:15 PM, Alex Zavatone wrote:
Right after clicking on an app's icon, the splash screen/launch screen shows
that the device has indeed paid attention to you and responded in the manner
you expected, namely, the applic
On May 15, 2012, at 02:13 PM, Kyle Sluder wrote:
On May 15, 2012, at 1:57 PM, Alex Zavatone wrote:
But that's the point, I'm never going to display an empty TVC.
Yes you are, because best practice says you're going to let your app finish
launching while you load your data in the backgrou
On May 15, 2012, at 2:35 PM, Alex Zavatone wrote:
>
> On May 15, 2012, at 02:13 PM, Kyle Sluder wrote:
>
>>
>> On May 15, 2012, at 1:57 PM, Alex Zavatone wrote:
>>
>> >
>> > But that's the point, I'm never going to display an empty TVC.
>>
>> Yes you are, because best practice says you're g
On May 15, 2012, at 02:22 PM, Jens Alfke wrote:
On May 15, 2012, at 12:56 PM, Alex Zavatone wrote:
We are caching (saving in a pList) the data from the previous launch. It falls
through and uses the previously saved data if we can't get to the internet.
Now, what I'm unclear on at this po
On May 15, 2012, at 2:45 PM, Alex Zavatone wrote:
> Rockin'. Exactly the information I was looking for. My only other question
> is what's the "best" approach for async requests? I've used GCD recently,
> but it appears that the frameworks have been advancing so quickly, it's not
> always o
On 5/15/12 2:35 PM, Alex Zavatone wrote:
>
> On May 15, 2012, at 02:13 PM, Kyle Sluder wrote:
>
>>
>> On May 15, 2012, at 1:57 PM, Alex Zavatone wrote:
>>
>> >
>> > But that's the point, I'm never going to display an empty TVC.
>>
>> Yes you are, because best practice says you're going to let yo
On May 15, 2012, at 3:10 PM, Conrad Shultz wrote:
> If I were to model an app, and maybe Kyle can jump in here for obvious
> reasons, I would pick OmniFocus. It sounds like it has similar broad
> behaviors to what you're going for. When I open OmniFocus, here's the
> sequence of events:
Yes, th
On 5/15/12 1:57 PM, Alex Zavatone wrote:
> But that's the point, I'm never going to display an empty TVC.
>
> Lame is how an HTML page loads with pieces coming in in varying order,
> with parts of the page appearing and then resizing and then graphics
> appearing and then being replaced.
> I don'
On May 15, 2012, at 2:50 PM, Jens Alfke wrote:
> Async NSURLRequest, as already mentioned. It’s a little bit clunky to use by
> modern standards — I wish they’d add some nice block-based callbacks to it
> instead of making me implement yet another delegate class — but it works
> well, and it’s
On May 15, 2012, at 7:29 AM, Koen van der Drift
wrote:
> However, the data read with the parser needs to end up in my Core Data
> model. Obviously I already created a Person entity, but how do I add the
> phone numbers to it? Create a PhoneNumber entity with two attributes?
That would be a reas
On May 15, 2012, at 3:33 PM, Marco S Hyman wrote:
> I'd disagree regarding the "quite well documented by Apple" part.
Have you read the URL Loading System guide, not just the class API docs?
> Is it possible for one of the delegate methods to be called before
> receiveData is initialized?
No.
On May 16, 2012, at 5:50 AM, Jens Alfke wrote:
>
> Async NSURLRequest, as already mentioned. It’s a little bit clunky to use by
> modern standards — I wish they’d add some nice block-based callbacks to it
> instead of making me implement yet another delegate class — but it works
> well, and it
On May 15, 2012, at 5:13 PM, Jens Alfke wrote:
> On May 15, 2012, at 3:33 PM, Marco S Hyman wrote:
>
>> I'd disagree regarding the "quite well documented by Apple" part.
>
> Have you read the URL Loading System guide, not just the class API docs?
The URL Loading System Guide contained the code
Guys,
I dont know where to post this problem so I posted it in the USB list
first but later realized its more of a kernel dev list. My problem is
that I need to be able to read the mice at the hardware level. I use
the new HID Manager API for this and the following work (perfectly):
1. Apple bluet
I can not for the life of me figure this one out.
Here is my code...
PRINT_APPEND(@"\n%d", [theAttributedString
retainCount]);
DESCRIBE(theAttributedString);
TRACE;
[the
I can add to this. For a long time we followed Apple's advice and had a black
screen with tabs at the bottom much like the built-in apps do for our launch
screen. Then one release we changed it to be more like a book cover with our
logo on it. Nothing else changed. Yet we got an enormous amount
On 15/05/2012, at 11:38 AM, Charlie Dickman wrote:
> Note that the retainCount has changed in the first case but not in the second.
> Does anyone have any ideas as to what is happening?
No, but relying on, peeking at or otherwise taking any notice of retain counts
is a sure path to madness.
A
I have an app whose current version has been out for over a month. Now, since
yesterday I received 6 layout constraint related exception reports (from 6
different users) with the signature shown below. I find that a bit strange,
since layout constraints are not date/time based, so why would th
42 matches
Mail list logo
