The question is as simple as:
Can an Apple Watch app have multiple glances?
I tried to put multiple glances in the Xcode storyboard but Xcode said that only one Glance is allowed for each app.
Reason I am asking this is that I would like to change the layout of the Glance based on the information I display.
But the question could also be phrased as:
Is it possible to
change the glance layout programmatically or
load different glances depending on the context.
Is any of the two possible? And if not, is there any indication that this may change after WWDC 2015?
EDIT:
To clarify. I agree, multiple glances seem not to be available, however changing layout of a glance may be (I personally think that they will allow developers to do so soon but as far we are concerned at the moment the only way I can change a glance layout is to choose it from the list provided in XCode).
Currently these are the layouts available for glances (top and bottom part). Ideally I'd like to choose them programmatically. If anyone knows how then please share some code snippet/sample:
Top part:
Bottom part:
An app can have 1 glance associated with it.
However it can be modified from time to time as per your requirement.
awakeWithContext() is called once for the controller. You can do general init work there.
willActivate() will be called everytime the glance controller is about to be initialised and you can request new data, change view there, do other awesome work, etc.
So to answer your question, you can load different glances depending on the context. But an app can have only ONE glance at a time.
Hope this helped.
The answer is as simple as:
No.
I'm not sure about changing it programmatically (haven't tried)
I don't think that you can load different glances.
The point of glances is to allow users to find one piece of info ultra quickly. For that, they need to know what they will be looking at. That's why there is only one glance per app.
Related
In CareKit there are Care Card and Symptom tracker. I'm not understanding how to customize Carecardviewcontroller and symptomtrackerviewcontroller. I don't want to use these view controllers but interested in using components of these view controllers. there is no clear documentation to explore this.
(source: carekit.org)
If you are coming at this from a Swift perspective, then it has to be admitted that CareKit is about as "un-Swifty" as anything you can imagine. The GitHub site is certainly a start, but there is a horrific gap between reading the programming guides there and actually implementing a solution. It certainly has been a long slog for me!
That said, you can add customization to CareKit's story-board-free approach by using the view controller delegate functions that CareKit provides.
For example, suppose you have an app that reminds your user to perform two intervention activities, (1) take aspirin and (2) go for a brisk walk. If the user opens the Care Card and taps an event icon (one of the circles) for "take aspirin" then that will fire a method in the OCKCareCardViewControllerDelegate called:
careCardViewController(_ viewController: OCKCareCardViewController,
didSelectButtonWithInterventionEvent: OCKCarePlanEvent)
In this method you can segue to whatever view controller you'd like. E.g. if the event is for taking aspirin then display a view controller that shows a photo of an aspirin table, a reminder that it should contain just an 81 mg dose, and a recommendation about taking it with water.
Of course, nothing is ever easy with CareKit. It turns out that you will probably also want to turn off CareKit's standard practice of calling an event completed if the circle icon is tapped. That is accomplished by returning "false" from another delegate method called:
careCardViewController( _ viewController: OCKCareCardViewController,
shouldHandleEventCompletionFor
interventionActivity: OCKCarePlanActivity )
-> Bool
There is a book called Beginning CareKit Development that I can cautiously recommend. It was written for an earlier version of Swift and you have to do a lot of "translation" to get things to work with Swift 3. The last time I checked the GitHub repository for the code associated with the book was also entirely in this earlier version. APress will provide the code updated to Swift 3 if you ask. On the Kindle there are numerous little glitches with the book, including an index that has no page numbers nor hyperlinks to the associated text, very odd formatting choices that make the text sometimes hard to distinguish from code, and occasional errors in the solution code. All that said, I doubt that I'd have made any progress with CareKit without the book's help.
I've been looking for this answer myself.
As far as I researched, you can customize this screen visually with UIAppearance.
AND/OR you can create a new screen like this one from scratch using its behavior.
You can check the CareKit source code for hints on this: https://github.com/carekit-apple/CareKit/tree/master/CareKit/CareCard
There you'll notice some interesting classes/files:
OCKCareCardWeekView
OCKWeekLabelsView
OCKHeartView
OCKHeartButton
OCKWeekViewController
OCKHelpers
CareKit draws each screen via code. You can see how they do it by reading the code.
The idea is to create your own ViewController with these pieces, or one from scratch.
Surely it's not as trivial as just using CareCardViewController, but this will get you there.
I am looking to implement a custom toolbar that sits above my keyboard for a text field with some custom values. I've found a ton of tutorials online but this question is for asking what's the best way to do this.
This tutorial here http://blog.carbonfive.com/2012/03/12/customizing-the-ios-keyboard/ provides the most common way I can see across many tutorials, with creating a new subclass of UIView and using delegates to get that information across.
That's the commonality. However, I came across this tutorial which in the view controller itself just creates the toolbar, assigns it to the textField inputAccessory and it's good to go. In fact, I tried out the code and without any effort, I have now a custom keyboard.
http://easyplace.wordpress.com/2013/03/29/adding-custom-buttons-to-ios-keyboard/
This just seems a bit too easy to me though and I'd think the proper, Apple recommended way would be to create that UIView subclass and use delegates so that the view controller with the text fields acts as that delegate.
I'm specifically targeting iOS 7 in my app.
What are people's thoughts on this? If the second easier link is supported and is likely to pass Apple's guidelines, it's a good starting point but if delegates are the way to go, I'd rather look into that from the start.
Your thoughts will be appreciated.
There is no 'Apple Approved' way to do this, and its hard to believe anything you do here would get your app rejected. The custom keyboard you reference in your post has the iOS6 look and will appear outdated in an iOS6 app. I'll mention some iOS7 suggestions shortly, but the constant danger of mimicking what the System looks like today is guaranteed to look outdated later. In Mac/Cocoa development, Apple use to say at the WWDC that if you did something custom, make it look custom, don't take a standard Apple widget and try to duplicate it. But that advice is mostly ignored.
For iOS 7, you can create buttons that appear just like the system ones do (not pressed), but of course when someone presses them, they won't act like system buttons (i.e. animate up and "balloon" out.
I'm currently using a fantastic add-on keyboard, my fork of KOKeyboard (which uses the buttons above). This is such a cool addition. While the buttons look like iPad buttons, each one has 5 keys in it. By dragging to a corner you select one of the four, and tapping in the middle gives you that key. This might be overkill for your app, but it really helped me with mine. It looks like this:
(the Key / Value is in the under laying view.) The center control lets you move the cursor - its like a joy stick - and can be used to both move and select text. Amazing class, I wish I'd invented it!
Also, for any solution, you want to use a UIToolbar as the view holding the keys, for the reason that it supports blur of the view it overlays, just like the keyboard does. You can use the UIToolbar with no bar button items in it (if you want), and just add subviews. This is a "trick" I learned here, as there is no other way to get blur!
David's KOKeyboard (er…, the one he used - see David's comment below) looks nice. I suspect that he is using the official Apple mechanism:
inputAccessoryView
Typically, you'd set that value on a UITextView, but it can be any class that allows itself to become the first responder.
The provided view will be placed above the default apple keyboard.
It is correct that there is no official mechanism (and it is suggested against) to modify any system provided keyboard. You can add to it, as above. You can also entirely replace it for with your own mechanism. Apply will forgo the keyboard setting on your view and use a custom input mechanism if you set
inputView
set it to any view - Apple will still manage its appearance and dismissal as it does the custom keyboards.
Edit: Of course, iOS 8.x added significant access to keyboards. (not mentioned here)
I want to design a page with tab bar on top of it.In some articles of this site.(i missed urls) i found that this is not a common way and the question gets some down rate.
The question is this: whethere having a design like this may cause that apple not approve the application on his store?
Even if it doesn't make Apple reject your app, think of the users not being used to the tab bar being at the top and how that is going to affect how well the app does in the Store.
Every platform has its own design patterns and there is a reason for that. If you stick to them there is a higher chance that the first-time users have an easier time using your app, which results in a higher chance that they keep using it. If they don't know how to use it or find it hard, they will move to another one.
Take a look at the Human Interface Guidelines and apply them. It will do good.
When the iPad first came out, I recall that Apple frowned upon the use of a Split View inside of Tab Bar Item View. Whether or not they rejected applications that used this design I don't recall or know anything of.
Is this design still frowned upon by Apple? If you create an application that uses this design will it be rejected by Apple? I know there are third-party API's now that help you write applications that utilize this design pattern which leads me to believe that Apple no longer cares, but I just wanted to be sure about this.
If anyone can shed some light on why Apple frowned upon this design that would be helpful because I don't understand what about this design was an issue for Apple.
I can't find the citation at the moment, but there used to be a section in the HIG that said that you must not do this, and then they changed it to one saying you should try to avoid doing this. So I think you're clear, as long as the design makes sense. Sadly I can't find where that phrase occurred — maybe it was taken out all together.
At any rate, there's nothing in the HIG under either tab bar or split view that says you can't do what you want.
I just stepped over this, too.
This also didn't work in the Interface-Builder prior to 5.1.
But i just tried today and recognized that you can simply add a relationship from a tabbar controller to a splitview inside interface builder (this did not work before).
However, only the detail view shows up when running the app and select the tab containing the splitview.
edit: This seems to work out very easy if you compile for 5.1. There seems to be a change in handling Splitviews.
Just try it out:
In your Storyboard, create a Tabbar Controller
add a Split View Controller
Create a Reference from the Tabbar Controller to the Split View Controller
Now you need to create your Master and Detail Controllers
I am not finished with the implementation yet, but hope this helps.
When using the Ti.UI.iPad.SplitWindow what is the best(cleanest looking) way to update the detailView?
The options I can think of are changing the positions of elements in the detailView event or to show()/hide() vs open()/close() on an orientationchange event. I know that using the native UI components on the iPad should dynamically update to the layout width/height of the iPad but in my case the content on each detailView will have it's child objects positions updated on orientationchange. I'm just trying to get the smoothest from your all experiences. Even if I have to build custom animations I just want to start this correct from the beginning so no current code exists yet. Thus none included.
I'm hoping this isn't a duplicate as I searched before I ask but there are no Titanium based questions on this topic I can find. Possible but still different to what I'm asking.
The smoothest experience will be delivered by changing the least. I don't know what animations you are envisioning, but I would nudge you towards keeping it simple.
Here's a quick example of an orientation change in an iPad app I built recently. I had a bunch of images in a view with layout: 'horizontal'. Due to a nice bug, the images wrapped automatically. When the user reoriented the device, I animated the width of the view, and the images automatically and animatedly resorted themselves.
I've also had some clients at a large corporation get their hearts set on really complicated changes to the layout whenever the user reoriented the device. This resulted in a really unsatisfactory app that took 10-20 seconds to reorient. We made a lot of optimizations, and a lot of improvements in both their code and the underlying framework, but the heart of the problem was the complex design.
Take the time to consider if you really need complicated changes every time the user reorients, and how much benefit you are offering to your users. Also consider the cost to the user (not just to the device) of presenting them with a new UI.
Past that, you're probably not going to get too many answers until you put some experimentation in to this. If you come back with some code and some questions to go along with it, I can reformulate my answer to better pinpoint your situation.
Hope this helps! -Dawson