Re: WatchKit Baby Apps

[Gary L. Wade]

Lots of people complain that Apple doesn’t listen to submitted bug reports, but 
they do, and as I was reading my emails today on my iPad, I’m reminded of two 
of mine that were answered, movement of the button for loading email images 
from the bottom of emails to the top, and adding an unsubscribe option. For SDK 
work, stringsdict was added the next cycle after I submitted a request to 
handle plural values in strings without writing extra code.

So, if you have issues, go to https://bugreport.apple.com and add your request, 
and if you have a solid way you’d like something done, be sure to add that.
--
Gary L. Wade
http://www.garywade.com/


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WatchKit Baby Apps

[Charles Jenkins]

Well, let me modify something I just said. If you’re writing an app to show
how many days until you reach retirement, WKInterfaceTimer is just the
thing to use. It’s not completely useless—it just doesn’t help with the
thing you really want, which is notification that the wait is over.

On Fri, Mar 2, 2018 at 7:50 AM, Charles Jenkins  wrote:

> The things you are describing are paths I already followed to dead ends.
> WKInterfaceTimer is truly and completely bogus. It just shows a
> countdown/count-up UI label while the app is onscreen. You have to pair it
> with an NSTimer set to count down to the same time in to make your program
> react in any way when the time period elapses. But lower your wrist, and
> the app and NSTimer are soon killed. I think WKInterfaceTimer is just there
> because someone though it could be used to make a cool demo app, not to use
> for any actual purpose. You could use both these objects in a game, when
> you’d know the user would be constantly interacting with the game and thus
> keeping the app alive. But they’re no good for any non-frivolous use.
>
> I already described my reason for not trusting local notifications: you
> can’t specify that they’ll alert you on the Watch, and you can’t be 100%
> sure they’ll alert you at all. What we need is a call to programmatically
> set the actual timer used by the Timer app, a way to schedule the app to be
> awakened at a specific time so it can play a haptic or do whatever it wants
> to get attention, or a way to set a local notification that will definitely
> always truly for sure be handled by the watch. WatchKit doesn’t give us
> those things because of Apple’s philosophical desire to prevent Watch apps
> that annoy the user. The very purpose of a timer is to annoy the user so
> he’ll be sure to notice and deal with something, so in my opinion it’s
> simultaneously the most useful kind of app you might want to create and
> exactly the kind of app WatchKit effectively prevents.
>
>
> On Thu, Mar 1, 2018 at 9:50 PM, J. Scott Tury  wrote:
>
>> Creating a WatchKit app with Timers should be fairly easy.  There’s a
>> nice interface object called *WKInterfaceTimer* which should  do the
>> trick - at least for the UI interface. Here’s a link to the
>> documentation:
>>
>> https://developer.apple.com/documentation/watchkit/wkinterfacetimer
>>
>> You might also be interested in reading the WatchKit Programming Guide.
>> It explains that WatchKit apps, are quite different from iOS applications.
>> The Interface is running in a separate process from your actual code -
>> which is running in a watch extension.
>>
>> https://developer.apple.com/library/content/documentation/Ge
>> neral/Conceptual/WatchKitProgrammingGuide/index.html
>>
>> Your extension does not run for very long.  Apple is extremely aggressive
>> about how much time a watch extension will run.  Running for a long period
>> of time is useful if you are collecting biometric data (heart rate, etc).
>>
>> A simple Timer application should be doable.  One of the challenges will
>> be how to tell your user that the timer has finished.  The simplest thing I
>> can think of is to schedule a *Local Notification*. That should be able
>> to get your user’s attention!
>>
>> Hopefully this helps you move in the right direction.
>>
>> Scott
>>
>
>
>
> --
>
> Charles
>



-- 

Charles
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WatchKit Baby Apps

[Charles Jenkins]

The things you are describing are paths I already followed to dead ends.
WKInterfaceTimer is truly and completely bogus. It just shows a
countdown/count-up UI label while the app is onscreen. You have to pair it
with an NSTimer set to count down to the same time in to make your program
react in any way when the time period elapses. But lower your wrist, and
the app and NSTimer are soon killed. I think WKInterfaceTimer is just there
because someone though it could be used to make a cool demo app, not to use
for any actual purpose. You could use both these objects in a game, when
you’d know the user would be constantly interacting with the game and thus
keeping the app alive. But they’re no good for any non-frivolous use.

I already described my reason for not trusting local notifications: you
can’t specify that they’ll alert you on the Watch, and you can’t be 100%
sure they’ll alert you at all. What we need is a call to programmatically
set the actual timer used by the Timer app, a way to schedule the app to be
awakened at a specific time so it can play a haptic or do whatever it wants
to get attention, or a way to set a local notification that will definitely
always truly for sure be handled by the watch. WatchKit doesn’t give us
those things because of Apple’s philosophical desire to prevent Watch apps
that annoy the user. The very purpose of a timer is to annoy the user so
he’ll be sure to notice and deal with something, so in my opinion it’s
simultaneously the most useful kind of app you might want to create and
exactly the kind of app WatchKit effectively prevents.


On Thu, Mar 1, 2018 at 9:50 PM, J. Scott Tury  wrote:

> Creating a WatchKit app with Timers should be fairly easy.  There’s a nice
> interface object called *WKInterfaceTimer* which should  do the trick -
> at least for the UI interface. Here’s a link to the documentation:
>
> https://developer.apple.com/documentation/watchkit/wkinterfacetimer
>
> You might also be interested in reading the WatchKit Programming Guide.
> It explains that WatchKit apps, are quite different from iOS applications.
> The Interface is running in a separate process from your actual code -
> which is running in a watch extension.
>
> https://developer.apple.com/library/content/documentation/
> General/Conceptual/WatchKitProgrammingGuide/index.html
>
> Your extension does not run for very long.  Apple is extremely aggressive
> about how much time a watch extension will run.  Running for a long period
> of time is useful if you are collecting biometric data (heart rate, etc).
>
> A simple Timer application should be doable.  One of the challenges will
> be how to tell your user that the timer has finished.  The simplest thing I
> can think of is to schedule a *Local Notification*. That should be able
> to get your user’s attention!
>
> Hopefully this helps you move in the right direction.
>
> Scott
>



-- 

Charles
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com