junior watch dev question list

I'm just catching up to some of your posts here, so let me see if I can answer these in a short and concise manner.

1. Each app only gets a single glance which is meant to show the most relevant and slimmed down information. A glance can contain multiple "scenes", though. Think of them as a single "window" into your application. Glances do not require a watch app (since are connected through the extension), but provide the best experience along side one. See Glance Essentials. Glances are managed only on the iPhone and communication is handled through WatchConnectivity.

2. This should be managed by your host app and synchronized with your Watch App extension. Ideally, you are only handling the synchronization of user sessions since you have no hand in the host app and the server interaction should be abstracted away from you. Remember, Watch Apps are companion apps, not independent apps.

3. See point above. You cannot have a Watch App without an iOS app, so sessions should be seamless to the enduser.

4. Your Watch App can be written in Swift while your host app can be written in Objectice-C, but you will need to bridge all of the appropriate things just as you would if the host was written in Swift importing obj-c components.

5. Mock it up, as in UI mock up? Sorry, not too clear on this one

6. Speak to them and how they handle this information. Ideally, you should understand structure without any need to know contents. However, they most likely have guidelines in place to handle working with secure data and other safe nuances. If they're asking you, I'd be quite concerned.

7. Git. 100% source control. You may as well break off a finger without proper control and management of source.

8-11. Speak to goals, what you want to achieve, how that relates to the people you are working for. Goals and relatable outcomes are the best way to resonate with people and this field particularly lacks it which can make technology and investment into technology very scary. You should also do your best to determine as many metrics as possible along with anticipating future platform growth (iOS 10+).

Timing is something that you'll have to gather on your own. It sounds as if you're just beginning to learn Watch App development, so the learning curve is going to set you back in multiple ways. First, there's the actual learning of everything, and then you'll need to refactor the initial code you conceptualized after you've reached that plateau in learning.

In your case, I see several setbacks already (from other threads and here). First and foremost is the lack of version control access and lack of access to the host app. If you have to mock together a host app, it will destroy you. If you have to copy and paste files and hope things line up, it will slowly chip away at you. You just cannot build a Watch app without a host, and it will be near impossible to build a good one that's based on mocked components. If you begin with glances, the moment you start working with WatchConnectivity you'll understand. The second, as I stated, is your level of skill and familiarity coming into Watch App development. You must read the Watch App programming guide before you plan or do anything, that's a given. There is a lot to take in and for all intensive purposes, it isn't iOS.

Overall, there's a lot of things for your situation that you need to take into consideration. One thing I suggest, well scream, to you is to not bite off more than you can chew and it sounds like you're very close to that.

 

Sort of, you don't need an app because the extension facilitates the communication but you need a WKInterfaceController subclass & storyboard glance entry to manage the setup of a UI. I'm sure that you've come across Managing Your Glance Interface, but if you haven't give it a quick read.
What you should be doing is setting up your different "scenes" as groups in your Storyboard and showing and hiding them based on whatever is most relevant. For example, rather than having an option to choose what you see there, the Glance controller instead determines that you have a pending unread message and communicates that to the end user by displaying the "new message" group and making all of the others invisible. If you were to not have a message, then the glance can hide the "new message" group and then show the "basic overview" group in that storyboard view.
Glances cannot be interactive and are meant to provide a user with the most relevant information without the user having to do anything other than bringing up your glance. Requiring your user to mess with an option to change that particular view, especially nested in an app, can quickly defeat that purpose so be careful with how you approach it.

No. At its core, the Apple Watch is not meant to be anything more than a companion to iPhone and that methodology extends into the way the inner components are built. Interactions are meant to be <10 seconds and use Handoff to encourage deeper and complicated interactions in their big-brother counterparts.

So basically: While Watch Apps can run independently of their iOS host apps, they require a host app to be distributed and offer oversight of the extension. In your example, a heart-rate monitor watch app would have to be packaged inside of an iOS host app - the Watch App focusing on gathering results & delivering quick information to a user (such as todays stats) while the full iOS counterpart would supply things like settings, extended history reports, editing, sharing information to social media, etc. There is just no way not to do this.

In an example that is relevant to you, let's assume the user can only download the Watch App. When they are prompted to log in for the first time (since a session could possibly not exist on the iPhone lacking your host app), how do they enter their details? There is no keyboard for Watch OS, at least not one that can handle usernames and passwords (this is a big reason there isn't a UI for wifi!) so how does your user enter those details? Do they need to go to another device and sign into a mobile app that presents them a number that syncs them to a service? That's complicated and requires another device anyway. If it was tied along side the iOS app, it means that instead your Watch App can hand you off to its host for gathering those details.

The running of the extension on the Watch has benefits that majorly impact developers and allow them to achieve a level of quality comparable to Apple's stock apps. For example, when responding to a tap in the UI, the Watch app extension can immediately determine the response; in Watch OS 1, that tap would have to make a trip to the iPhone to get the proper response and then round back with the details for the reaction. That time is eliminated with native apps. The ability for an app to run independently of an iPhone is more-or-less a (of course wanted) side-effect of this.

There are also a few other things: With NSURLSession, you are able to fetch information from the web without having to round trip to the host app which contains this information. This, of course, presents a lot of options to the developer and how they want to manage their data to make it perceivably instant to the end user because things like Watch Connectivity allow you to queue information for processing. I really suggest watching this chat about WC and interactions with your parent app - it will help show you the value of building the two together.

~~

As for your other things, yeah, you'll only need a single header. And as far as having the GIT, thank jebus because you would have had no way of doing this project otherwise.