Mobile App Development for the Non-Mobile App Developer

Developer Tools
1

I have been thinking about this for a while and I can’t believe I am the only one. So, I thought perhaps I could start a new thread where the last one left off (closed after 180 days - sigh) and see what people are using or could recommend.

https://community.particle.io/t/mobile-apps-talking-to-particle-devices/58199/7
I would be interested in hearing more from @ctmorrison on his experiences and perhaps we can carry on the conversation here.

I think a reasonable place to start would be to talk about what a mobile app should be able to do. As I am new to this, please feel free to suggest more requirements if I am missing something:

Single Sentence - A cross-platform mobile app that I could give to members of my product “team” that would allow them to have access to the functionality of the Particle Mobile App or Particle Console but with a better UI.

  • Identity - I am thinking this is someone’s Particle ID and what they could do would be based on their role in the Particle product team. I am thinking that this uses Particle’s Team Access Controls.
    Team Access Controls | Tutorials | Particle
  • Scope - The number of devices this person could see / interact with would be tied to the product. They would see a device list as they might if they were logged into the Particle console
  • Functionality - The user could interact with a device and get information equivalent to the Particle console with, perhaps, a more intuitive interface. This would include Particle Functions and Variables as well as device health
  • Provisioning? - I am less sure on this one as I think it becomes much harder to manage scope / roles here but perhaps this is possible too - again based on product roles.
  • Cost - I don’t know how much these applications will be used and I don’t want to sign on to some huge up-front development contract or high monthly bill until I get a sense. Is $50 / month unreasonable?

Again, if I can thinking too big / small here. Please let me know.

Here is the post that got me started

I have done some looking into different options but am hoping there are more:

Flutter - https://flutter.dev - Cross-Platform development from Google. Broad support but no quick start for Particle. Also, seems to have a steep learning curve compared to the other options here.

Branded App by Wix - https://www.wix.com/app-builder - No code development but no Particle integration in their App Store. Low price (at least for now) and ability to publish to mobile app stores.

.bubble - https://bubble.io/ - Another no / low code option but also lacking a Particle integration. Also pricing get to $500/ month pretty quickly.

Thunkable - https://thunkable.com/ - This is the one the @ctmorrison was talking about and it looks fairly slick. I don’t see a native Particle integration and it also seems like it could get expensive quickly if you go professional.

Particle Mobile Tools / APIs - iOS SDK | Reference | Particle - This list would not be complete without mentioning these. Has anyone figured out an easy was to adapt the Particle Mobile App to meet their needs. It seems limited to showing devices only to the “owner” and not members of the product team using team access controls.

One idea started to form in my head. If we, as a community started to develop a preference for one of these approaches, perhaps we could get a Particle integration developed for that platform. This could make it easier to get started. Just a thought.

Please let me know what your thoughts are on mobile application development and perhaps we can share our example apps here too.

Thanks,

Chip

2

Hi @chipmc, This will be an interesting thread to follow and thanks for getting it started.

With regard to Thunkable, the tool keeps getting better and better and easier to use. In the newest form (“X”?), it’s far more flexible and easier to build an interface. The beauty is that it generates both iPhone and Android applications and they facilitate getting them submitted to the respective stores. I’m paying $19/month and don’t feel that’s bad for the ease with which I can post an app for each platform. That being said, the real hurdle was meeting Apple’s App Store requirements. It took far more effort than I anticipated.

The block language seems rather natural, although I sometimes miss simply writing out the code. Here’s a snippet of one of the blocks to implement a Particle function call based upon a button push:

Thunkable
Thunkable1280×1492 242 KB

Granted, I’m only working with Particle Developer devices at this time and more effort would be required to implement user authentication for Product devices.

I’ve written a few apps for various needs and I do find it relatively easy, once I got the gist of it. I’m pretty sure at least one or two of my apps are Public on the Thunkable site and could be used as a starting point for a new app.

Since I wanted to put at least one app in the hands of customers, I had to come up with a way to obfuscate the API key. If someone reads my crude code and had a sample of a scrambled key, they’d be able to cause me headaches until I created a new key. But that was a conscious decision on my part to get something into the field.

I hope this thread ends up being valuable and, again, I’m glad you got it started. I’ll offer more as appropriate and/or answer any questions that I can.

1 Like
3

I like this single sentence definition but had a few clarifying points/questions. Is this intended as an end customers, tech savvy customers or only for a member of your product team that support customers? Would this be a custom mobile app tailored to your specific product (i.e. call this specific function on this specific device as part of this specific product) or a mobile app that any Particle community person could use (Like the current Particle Mobile App or the Console that queries your list of devices, products, functions, etc.)?

I personally have not looked at native mobile app development so I can not comment on the low code/no code options referenced. It's intriguing though. To date, I've just stuck with web app development with a mobile first web app approach primarily through Bootstrap responsive design. That way the same content in the web app is presentable in an acceptable UI whether it's displayed on a desktop, tablet, or mobile device. For example: image

If the intent is to have the content available at console.particle.io to be available on a mobile device with a nice UI, I wonder if the console.particle.IO native web page could be refactored a bit into a "mobile first" web app with a responsive layout based on the size of the device accessing it? It seems to have aspects of this but it still is very clunky. When I'm in a bind and need to access the capability of the console, I still just go to Console.Particle.IO from my mobile phone's web browser. It's definitely clunky and hard to navigate from a mobile device to the place to call a function but it certainly has what I need. If the various components of the console were refactored with this more responsive design would accessing it from your mobile phone's web browser be sufficient or should it be a simpler interface?

2 Likes
4

@jgskarda,

Thanks for the response and for adding another approach to getting what I am looking for.

I like that you started with the objective. My first pass would be to develop an application that the tech savvy folks on my product team could use to support the end users. Think of the State IT department or product managers accessing the data in support of individual parks. An end-user app with more limited functionality would be a great follow-on however.

I understand the concept you are conveying, and if it could be realized, this could make things much easier. I also occasionally go to the Particle console but find is very painful to use on a phone and this is not something I would want to subject my users to. Would it be possible to make it a “mobile first” (or at least first-class) responsive design? Would this be something Particle would have to do or could I “screen scrape” their pages?

Thanks the great idea. I guess there is another option to consider in my quest for the best solution.

Chip

5

@chipmc I have been using Appsheet for years for another project, and it is great. If you could push the data you are looking to interact with to a google sheet then you would be gold to use Appsheet to access it.

1 Like
6

@Backpacker87 ,

Interesting as I have been working to get my configuration data to a Google Sheet for some time now. Currently running into some App Script issues.

Once I work these out, it may be another way to get data to the user and build links back to the devices via web hooks.

Thanks,

Chip

7

Unfortunately, I’d think this would require Particle to do the work or possibly a front end developer willing to do a little heavy lifting on behalf of Particle. When I mentioned the idea that’s what I had in mind at-least. The value is that all particle users could benefit from this but certainly would take more work I think. From my perspective only the product devices page needs the overhaul to provide most of the value and improved interactivity from a mobile phone. The rest of the console could be left as is in my opinion.

As you know, I built a custom backend and webapp for my own IoT project. Not sure if I started over if I’d try a no code/low code approach or if I’d still go with a custom web app like I did. I think it comes down to what specific functionality a user requires, how scalable you want to make it and how much you want to spend time learning yourself. Personally, I think I would of been well served doing 1 season of a low code/no code approach to get quick feedback from users on what features deliver the best value and then build those features into a more refined web app.

So I’d ask yourself, what is the minimal amount of information and functionality needed to allow a tech savvy folk to support the end users? Is this just viewing device vitals and calling a function on a device? Updating device config settings? If the no code/low code approach can meet the minimal amount of functionality I’d think it’s a great approach. Allows you to get feedback and iterate quickly and proves out their is value in having it. If the functionality is beyond what you can quickly accomplish then maybe time to develop a web app with that functionality.

Some of the best advice I had early on when I started asking people how to build a mobile app was to not build a native mobile app at all, rather build a web app. From there someone else told me easy way to start is Python Flask. From there I watched a few YouTube series and forked a few GitHub projects and it’s been building and learning ever since. It’s certainly been fun learning along the way.

I don’t have hundreds of users yet but for me, the universal feedback on the web app built so far is everyone loves the simplicity of it and no one minds opening a web browser via a saved favorite vs having a native app on their mobile device. Depending on your customer base, keeping it as simple as possible is the best approach, especially to start.

1 Like
8

Hey there,

since you mention Flutter, we can also include in the list:

The Ionic Framework

React Native

They do have their learning curve, but if you are a web developer you'll feel at home.
For Ionic at least you can use the PARTICLE API JS SDK, and I suspect for React it would be the same.

Great discussion!

1 Like
9

@gusgonnet ,

That is a great point. If I understand what you are suggesting, it is to use the Ionic Framework or native React with the Particle JavaScript API to make a cross-platform app (desktop to mobile) which is, I think, along the same lines that @jgskarda is suggesting albeit with different tools.

I am still hoping to find Particle in some framework’s list of existing integrations - no joy here:

But, again perhaps this is something we can ask Particle to consider doing or, perhaps something one of our amazing community members might do.

Thank you for adding to the list. Will run this a bit longer and then take a stab at a summary.

Chip

10

While there is no "official" Ionic-Particle integration, we can use the Particle JS SDK as a library in our apps. So I see no need for an official one.

There is another framework called NativeScript that does have a Particle integration:
https://market.nativescript.org/plugins/nativescript-particle/

@bsatrom wrote about it some time ago here.

11

@gusgonnet ,

OK, I see the SDK will suffice.

Thanks for the NativeScript link - another one for the list.

Chip

12

I wouldn’t put too much weight on if the framework having a Particle Integration. I will say having a defined integration to Particle might make things a little easier but it seems anything that a Particle Integration does in 1 line of code, can be done via a Particle Device Cloud API making an API HTTP request to in just a few lines of code.

For example… this is Python code that is used to call a function on a device on my backend. Any web framework would use something similar to make API calls to the Particle Cloud. In Python it’s Requests library to make any HTTP requests. In this case, a user can click a button in my web app. This makes an API call to my backend (the code posted here). My python Flask first confirms the user that made the request is the owner of that device (queries my SQL database) and then makes an API call to the Particle Cloud to call the function using a token.

@api.route("/api/callFunction", methods=["GET"])
@jwt_required
def getFunction():
    device_serialnumber = request.args['xxx']
    function = request.args['function']
    args = request.args['args']

    device = Devices.query.filter_by(xxx=yyy).first()
    if not device:
        return(jsonify(msg="device not found")), 404

    request_oid = get_jwt_identity()  
    if request_oid != device.owner.oid:
        return(jsonify({"msg":"You are not the owner of that device"})), 403

    data = {
        'arg': args,
        'access_token': current_app.config['PARTICLE_TOKEN']
    }

    response = requests.post('https://api.particle.io/v1/products/'+current_app.config['PARTICLE_PRODUCTID']+'/devices/'+ device.device_id +'/' + function, data=data)
    dictFromServer = response.json()
    returnJSON = {'return_value':dictFromServer['return_value']}

    return returnJSON, 200

My current limited understanding (and yes, very limited) of the Javascript SDK is it is more meant for backends running node.js and not necessarily the front end (similar to the code above that runs on the backend). If it’s meant for the front end in a web browser, maybe there are better ways than I know. The challenge for me was not exposing tokens, credentials, device_ids to the front end if all the code is in the web browser. For certain things, it feels like you’ll always need a backend to not expose credentials/tokens to the web browser. That might be done different in a React.JS framework though… I’m still very much learning in this space. That said… I’ve been contemplating learning React.JS and revamp my current web app (even if it’s just to learn). Maybe next summer.

2 Likes
13

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.