[Feature Request] App and widget in one binary

in my humble opinion I don't think it would make sense

I discussed this quite a bit at the developer's conference in April with @MoxyRoger.

My thought was that there would be a few bits reserved in the PRG file header to specify the different ways the app can be used. The system would use these bits to decide how the app could be started, and there would be an entry point for each of the different ways an app could be used. Something like this:

class AppBase {

enum {
APP_TYPE_DATA_FIELD,
APP_TYPE_WATCH_FACE,
APP_TYPE_WIDGET,
APP_TYPE_APPLICATION
}

function getApplicationView(appType) {
// overridden by derived class to provide a view appropriate for
// the given app type. the default implementation just calls the
// getInitialView function for compatibility.
return getInitialView();
}

// keep this for compatibility
function getInitialView() {
}
}


An app would just need to provide a view and an optional delegate for the application types that would be supported.

function getApplicationView(appType) {
if (appType == APP_TYPE_DATA_FIELD) {
return [ new DataField() ];
}
else if (appType == APP_TYPE_APPLICATION) {
return [ new ApplicationView(), new ApplicationViewDelegate() ];
}

return null;
}


The big concern would be the amount of memory used when implementing the smaller app types like data fields. Maybe we could do something like we do for background apps and use annotations to include code:

(:application)
class ApplicationView extends WatchUi.View
{
// not loaded when running as a data field
}

(:data_field)
class DataField extends WatchUi.DataField
{
// not loaded when running as an application
}

(:application :data_field)
class ApplicationModel
{
// this is used for both data_field and application apps
}


I think it would be a lot of work, but this does allow apps to do nice things easily. For example, you might want to write a data field that captures data (number of pitches thrown) to a fit file, and then a widget that shows the number of pitches thrown every day for the last week.

Maybe it would be a better solution to just allow different apps to share the same object store or for app developers to just store all of the data in the cloud. I'm not sure which is better, but I do think the idea is interesting. I'm just not sure how much traction it could get.

Hi Travis,

I was thinking about something similar, the concept (including example code) sounds like a very good solution in my opinion. In fact my thoughts were more about "only" allowing apps to provide widget views, but why not do it even more generic :)

Would be great if you could talk about this kind of change internally and inform us whether there is a chance this will be included in the SDK or not.

Thanks again!

Bye

I'm not sure how often this would be used. If the goal is just to have access to a common Application storage for the different app types. maybe stick with seperate.prgs, but look at a secure and safe way (maybe with some sort of versioning) where an app and widget can share one store without using a cloud and it would also work for all app types. Code sharing can be easily done with barrels, were for example "common" code could be one or more barrels, with app type specific code on top of that. ( I already use a barrel for a "background", when the same thing is used in multiple apps, and barrels for common things I do in multiple watchfaces and device apps)

Going with something like this would also allow sharing data between multiple widgets, where the single binary approach wouldn't.

I would surely use it, as such a "direct" integration is much more convenient. Not only for the developer but also for the user.

For now I have created a widget for my app that provides limited functionality. Still I'd like it a lot if the above mentioned concept by Travis would be considered again.

Bye