I restarted my connectiq developments again (after getting myself a new watch) and wanted to start using barrels to make life easier. But most apps I have made now support just about all devices and of course this leads to issues with barrels NOT being supported by all of them. So my questions are: From what version onwards are barrels supported, is that 1.4.x? (And are they then supported by all devices from then on?) Is there a way to make one app, use barrels for those devices supporting them and use the sourcecode IN the barrels for example for the non-suppporting devices? Now I just have a 'common source' project and copy the .mc and other files I need, but using barrels would be helpful and nice. But if that would mean dropping support for devices, or maintaining 2 versions of the app... meh.

Use barrels for supported devices only, use it's sourcecode directly for others?

I restarted my connectiq developments again (after getting myself a new watch) and wanted to start using barrels to make life easier. But most apps I have made now support just about all devices and of course this leads to issues with barrels NOT being supported by all of them.

So my questions are:

From what version onwards are barrels supported, is that 1.4.x? (And are they then supported by all devices from then on?)
Is there a way to make one app, use barrels for those devices supporting them and use the sourcecode IN the barrels for example for the non-suppporting devices?

Now I just have a 'common source' project and copy the .mc and other files I need, but using barrels would be helpful and nice. But if that would mean dropping support for devices, or maintaining 2 versions of the app... meh.

0 jim_m_58 over 3 years ago

Yes. my barrel projects are that way for that reason - not all devices support barrels. With eclipse, it was a bit easier, as Eclipse had it's own links so you could just link the files. With VS Code I use jungles.

Here's an example of the monkey.jungle file I use.

project.manifest = manifest.xml

srcBase=source
resBase=resources

#barrels background
barBgWu=..\BgWu
barBgOWM=..\BgOWM
barBgSettings=..\BgSettings

#barels misc
barSenHist=../SenHisMisc

#barrels clocks.
barClkGoals=..\ClockGoals
barClkFields=..\ClockFields
barClkIcons=..\ClockIcons
barClkMisc=..\ClockMisc
barClkSettings=..\ClockSettings
barClkSun=..\ClockSun

#watchfaces, etc
#using fields and sun
#base.sourcePath=$(srcBase);$(barClkFields);$(barClkIcons);$(barClkMisc);$(barClkSettings);$(barClkSun)

#using goals
#base.sourcePath=$(srcBase);$(barClkGoals);$(barClkIcons);$(barClkMisc);$(barClkSettings)

#Weather underground
base.sourcePath=$(srcBase);$(barBgWu);$(barBgSettings)

There are other cases where you may not want to use the barrel but just share the mc file, as for each barrel, there is some overhead added.

0 FlipStone over 3 years ago in reply to jim_m_58

Thanks but I don't quite understand, how is that actually working for a barrel-supporting vs non-barrel supporting device. Does the compiler/ide 'know' what to use automatically? Or do you have to specify alternative paths for the various devices?

Am looking for a more extended source/github example but can't yet find any...

0 jim_m_58 over 3 years ago in reply to FlipStone

For a single project, you aren't mixing barrels and no barrels. It's barrels or it's not for all devices for an app.

But it's all the same shared code. With the monkey.jungle file I posted, it's pretty straight foreword - there I'm not using the .barrel file, but shared source.

In that case I have 2 barrel projects used in the main app - BgWu and BgSettings

And what I'm doing here

base.sourcePath=$(srcBase);$(barBgWu);$(barBgSettings)

is just setting sourcePath to be the normal source folder, as well as the source in the BgWu and BgSettings barrel projects

0 FlipStone over 3 years ago in reply to jim_m_58

So that would mean compile two different apps, 1 for barrel vs 1 for non-barrel devices right?

But then using shared source would have my preference I guess, thanks for the info and explanation btw. Much appreciated!

0 jim_m_58 over 3 years ago in reply to FlipStone

No, it would mean when you change something in a barrel project, you rebuild the barrel project.

When you rebuild the main app, it will either use the .barrel or the .mc files directly, where in both cases, the code is the same. A .barrel file is really just a .zip for the barrel project, and when you build the main app, it gets unzipped and built.

0 FlipStone over 3 years ago in reply to jim_m_58

Hmmm, sounds good but need to dive into it some more because i still have no understanding how it actually works :p

Now, when trying to run a barrel projectr in the emulator on a non barrel device, i simply get an error. But guess that's a matter of setting the jungle file and all up properly.

Good to hear it should work at least, cheers!

0 jim_m_58 over 3 years ago in reply to FlipStone

You may find that you prefer not using the .barrel, and just the common code, as there is an overhead using the .barrel. About 1k last I looked.

0 FlipStone over 3 years ago in reply to jim_m_58

Yeah, will take that into account too... Seem to have it working now using your jungle example above.

No clue if it now uses barrels in the background or if I just use the source directly but most important thing is that I can now adjust the common code in a single place and I don't have to copy around... Cheers!

0 jim_m_58 over 3 years ago in reply to FlipStone

The BgWu barrel I used as an example can be used in a background services, but it was also written in such a way I can use it from the foreground/main app. In one of my widgets, I just use it as shared code, as that widget runs on about every device.

0 peterdedecker over 3 years ago in reply to jim_m_58

jim_m_58 said:
You may find that you prefer not using the .barrel, and just the common code, as there is an overhead using the .barrel. About 1k last I looked.

It's unfortunate that barrels are not supported on all devices. For me it's the main reason I'm not using barrels anywhere.

As it is now I can't see much advantage to using a barrel:

+ you can define shared resources and source code as a single entity

- it doesn't support all devices

- there's memory overhead to include and use the barrel

- your barrel code needs to be able to function on it's own, you can not define expectations (depend on functions that you will implement in your final project).

I think the poor man's barrel (using the monkey.jungle and overriding base.sourcePath) is the better alternative

base.sourcePath=$(base.sourcePath);..\shared