Library search, forkable library examples, and private libraries shipped to IDE

Hey there folks,

I wanted to give the heads up that a couple of library related features were just deployed to the IDE. These features are pretty straight forward but there are some concepts that merit deeper explanation and discussion.

Forkable library examples

If you have a core connected, you can now try a library without typing a single keystroke: click “use this example” then hit the flash button: boom, a binary being flashed to your core that exhibits the library in action.

We’re hoping library authors embrace this capability by including awesome example applications when they publish libraries. As we all know, usable documentation is great; but executable, editable documentation is better because it allows people to interact and see the magic in action.

Attention library authors: This feature is for you. Show how awesome your library is by documenting the required hardware and assembly instructions well in the README and providing kickass examples to illustrate how stellar your library is.

Private libraries

This feature was introduced to make it easier for people to test and verify that libraries work as expected before they publish them to the broader community. It is also the first step toward enabling a modern GitHub-style development flow for community library refinement.

When you hit the “contribute library” button, you’ll be taken to the same library validation page as before, however, instead of publishing them immediately after validation, you’ll “import” them–which makes the library usable within your apps (i.e. a private library).

After you’ve imported the library, you can give it whirl by simply clicking “use this example” on one of your library examples then hit the flash button. You can also include into an existing app just like a published library. If you need to make subsequent refinements to the library, you’ll need to bump the version up in the spark.json, commit some changes to the repo, hit the “contribute library” button again, and import it in again. You’ll then have a new library version you can test against.

Library development flow

To contextualize these features, the following describes the basic process of how you contribute a library, test it, and ship it publicly. As we enhance the library system in response to people’s feedback, our concept of development flow will evolve, but right now here is the happy path:

  1. Identify a need for code reuse or opportunity for code sharing in your applications.
  2. Click “Contribute Button”, add your GitHub repo containing your reusable code.
  3. Get your library code past the validator to that ensure it’s structured the way it needs to be.
  4. Click “Import” so you can use it in your apps.
  5. Use it, test it, flash apps with it, make sure it works as expected
  6. Click “Publish” so others can use it in their apps and flash your forkable library examples.

As always, please let us know what you think! We thrive on the feedback you guys provide us.




This is fantastic!

I noticed that the search is case-sensitive - which makes for a fun guessing game given that the library names are always displayed in upper-case! :wink: E.g. try “web” vs “Web”.

1 Like

All these are cool features!

1 Like

That’s annoying! Just pushed a fix to make this case insensitive, like you’d expect. Thanks for pointing that out! :smile:

Hi guys, I’m porting RCSwitch library to :spark: Core and found an issue with importing it to IDE:

Original version is 2.52 which in semver would become 2.52.0 but apparently it’s invalid:

Should I split it into 2.5.2 or this is just a bug in Web IDE?

Yo @suda , thanks for porting the library and good question (and good to see you here too, last time was in Poland at MakerLand over beers I think :smile: )

Look’s like you figured it out and published your library, which sweet. You also surfaced a bug in the library version validator: It current expects each x,y, and z of X.Y.Z to be single digits, so the 52 was causing it to fail. Haven’t fixed this yet, but will do soon and ping this thread.

Thanks again for porting the library!

Hi Joe :smile:

I temporarily changed version to 2.5.2 but will update to 2.52.0 as soon as this bug will be fixed.

P.S: Nice to see you too :slight_smile:

Seeing as this is a library related little bug, I thought I’d post it here. It turns out that some libraries have become so popular that the number of apps they’re being used in is becoming too big. A picture says more than a thousand words:
Increasing the width by a few pixels seemed to fix the problem, so it’s only space related. I’m sure you can come up with a better solution to this minor annoyance, so I thought I’d let you know.

Thanks in advance!

Seeing as this is also space related, and just a really small thingy, I thought I’d add it here so you could look at it in one go; When you scroll through your code in the IDE, and you pass the 99th line, the line indicator makes a jump in size. It goes from 47 pixels (0-99) to (100-999), creating a visually annoying “jump”. It’s nothing big really, but it’s one of those things you’ve been annoyed about but have learnt to live with. Seeing as you’re always looking for things to improve, I thought I might add this one to the list.

Tagging @jgoggins, whom I believe is responsible for the web related Spark magic :wink:


Sorry for the delay @Moors7 acknowledging this great suggestion, was taking a much needed vacation for the last week. It was easy to replicate the second “EDIT” suggestion you made for me and I added it to the IDE backlog.

I wasn’t able to replicate the first one you mentioned though about library “included in app” numbers. What browser and OS are you using? I don’t see on OS X 10.9 + Chrome.

1 Like

Hey @jgoggins, don’t worry about the delay, it’s no big issue, and you’ve earned your vacation! Thanks for adding it, like I said, it’s no big deal, but it would be nice to see it fixed.

Concerning the Libraries:

I’m running windows 8.1 64 bit.

Div id=“ember1072” seems to be the culprit. Its current width is 219px. If you increase that to 232px they’ll line up more nicely. Apart from that, it’s sometimes still hard to see due to libraries which have titles that spawn two lines. Would it be possible to highlight the number of apps along with the library title upon hovering? Maybe insert horizontal rules between the titles/numbers to create a visual separation?

Let me know if you need any more info. Thanks in advance!

You could not have provided more useful, detailed information to squash this bug sir @Moors7 :smile: . Thank you very much.

1 Like

@jgoggins @peekay123 is the limitation of only one true library still valid?

Curious if the following can be done (Just an example, do not actually want these three includes)?

#include "TinyGPS/TinyGPS.h"
#include "neopixel/neopixel.h"
#include "FastLED/FastLED.h"

If not, is there a workaround other than loading each include into the project?

There is no such limit.
You can use as many libraries into your sketch as you can cram into the flash memory of your device :wink:

What gave you the impression there was such a limit?
Could it have been the even smaller flash of the Core not allowing another lib next to a big lib/sketch?

[quote=“rocksetta, post:14, topic:5459”]
If not, is there a workaround other than loading each include into the project?
[/quote] The ONLY way to have multiple libraries in your app on the IDE is to attach them. Just adding the #include reference will not do that automatically.

Can you explain how to attach them. When the IDE does it automatically it works fine, when I only add the #include statement it does not work.

You need to go through the whole process of adding any used library to your project for each individual one.

As mentioned in another post already you can imagine a Particle Build project to be stored in a remote direcory on a Particle server and in order to build all required files have to be “inside” that folder.
So if you just add an #include statement the compiler won’t find the required files inside that folder.
But “importing” or “attaching” the library will “copy”/“link” the required files into your project folder so they can be used.

Here is what I am finding strange. When a user clicks the library “Use this Example” button, the particle IDE makes a working example. That is great, really really great.

However, if I then copy that code and make my own .ino with that code, it does not compile.

The IDE is doing some linking of files in the background. Can I do the linking manually?




Any idea how I can get my own apps using the internal includes such as

#include "neopixel/neopixel.h"

I can see that the NeoPixel is included in the A-Rainbow.ino, but I do not know how to include it in my own app.

Give the “include in app” a try?

1 Like