Best practices for multi-device support without layouts?

After doing some prototypes, I made the decision not to use layouts (or drawables) for my METAR/TAF widget. I did this for several reasons but it was mostly because there are limitations in terms of reuse and run-time configuration of the attributes. I think these limitations are likely a result of the fact that layouts were really designed for supporting multiple devices over static (or semi-static) layouts.

Regardless, the way I'm doing it with x,y positioning works really well, is clean and is fast. However, the design only works out of the box for the D2 Bravo (and the fenix 3). To support other watches I need to modify some (but not all) of the positioning x,y numbers. Is there a good way to do this that doesn't involve hard-coding values per device (or device family) in the code? I've been exploring the use of resource-based properties but because that requires a variable and a call to getProperties() for each one it seems inefficient. I also though about using resource-based strings, which I could convert into numeric values but that is an even worse kludge. Am I missing something simple?

Cheers,
Douglas

travis.vitek over 9 years ago

Is there a good way to do this that doesn't involve hard-coding values per device (or device family) in the code?

This is exactly the problem that using a layout solves. It abstracts the placement details into a device or family-specific configuration file. Of course there is a cost... :(

Am I missing something simple?

I know that some guys have taken to writing custom draw code for each device. They use the App Export Wizard to generate the .IQ file for each device, then they crack them open and make a single .zip file for all devices. I'm not certain that this will play well with the 2.x SDK stuff, but it is what others have done.

Travis

jim_m_58 over 9 years ago

I put the device-specific logic in onLayout(). Using width and height, you determine the screen size, set a boolean which may be need in onUpdate (such as isSemiRound), and set variables for the font for different things, and the x's and y's that vary by device. Then in onUpdate, just use those variables. I'll use the booleans in onUpdate for things like I may have to display a sting differently on a va-hr (skinny screen) than on a semi-round (wide screen)

The result is the same .prg will work for whatever watch it's run on (with some oddities like the bitmaps being weird colors, but can happen during testing! )

dbrobert over 9 years ago

This is exactly the problem that using a layout solves. It abstracts the placement details into a device or family-specific configuration file. Of course there is a cost... :(

Yeah, I'm not concerned so much about the cost as the flexibility. For example, I have a rectangle that changes colour depending on some data (weather conditions). I wasn't able to figure out a way to change the colour of that element at runtime, while also allowing the element to be used in multiple locations. Plus I found that mixing layouts with manually drawn elements got complicated in terms of how things are called. It seems that you can position elements manually or you can use layouts, but not both.

Now that I've been using the SDK for a while, I might try using layouts again and do a trial refactoring. I've ready that layouts are more memory intensive but has anyone looked at the responsiveness of layouts versus manually positioned elements? I'm more concerned about widget speed than memory.