Most recent activity
-
While I agree with some of your points, mainly that "it would be great if everything worked on web", but I don't think it will happen this way. It's more of a dream thing than reality. Let me share my thoughts on it.
Mobile web usage is eating desktop web usage, it's a fact. Already. Which leads us to a thought: who will be defining the web experience: desktop or mobile. For me, the answer is pretty obvious.
Mobile web user experience is very different from desktop. Starting from interactions to performance-related things (switching tabs, reloading). So, taking into account the statement above: mobile will define the web, ux will be different and of course mobile oriented. Not sure will it be browsers, we'll see. I believe that experience matters, but today ordering a taxi in a web browser is absolutely different from taking an Uber in a few touches in the app.
Responsiveness, for me personally, is a myth. I even made my own user research (~60 respondents) and it shows that users clearly prefer full-version websites over those adapted for mobile. Why? Mainly because...they can't zoom! I know it's funny but it's a reality. Also, mobile versions obscure website's functionality (e.g "hamburger menus" - no one sees them/don't know what it is). If anyone can show me a really well done really mobile responsive website - please do so(rearranging the blocks doesn't count). The only exceptions are sites designed "mobile-first". BTW, we already see preparation phase for responsive mobile design. Just look at "flat" design, "material design" by google. I think it's a logic evolution for interfaces that should work across platforms, where accent is no longer on assets, but on code which define scaling, padding, coloring, etc.
While I'm absolutely not excited about supporting variety of resolutions and platforms, :) it seems that this is the only one path today. Web is not even close to solve it. I hope that mobile will (finally) be able to render vector graphics and since then we will see fully responsive mobile design without worrying about resolutions.
Again, these are my thoughts, and I bet on mobile :) definitely not web.
-
Our protocol supports main 6 commands:
digitalRead/Write analogRead/Write VirtualRead/Write"Virtual Pins" were designed specifically for Blynk to allow sending any data (e.g String, ints) to the app and back. This is one of the reasons why we didn't use Firmata.
There are two layers. 1 responsible for connection , 2nd for commands processing.
We build Blynk hardware agnostic and now it supports almost every popular maker's hardware and shields on the market. You can see full list here - and it's constantly updating.
BTW, We have lots of requests from Espruino owners to add it to Blynk. We would love to see Espruino there, we just have no time for it now. May be someone from that this amazing community will initiate it and we will help.
There were a few comments on security. Well, it's hard to implement software security on Arduino. You can achieve it by connecting to the hub, or adding hardware security. More powerful devices will of course have more options. All the other connections (Apps <-> Server) are using mutual SSL. If you connect over USB- we also provide security.
Since our server is open source - you can download it and install locally, even on the Raspberry Pi - this will give you full control of your network of devices.
Regarding flexibility:
Here is an example for Arduino UNO with Ethernet shield. There are just a few lines of code in order to get Blynk running. And they don't interfere with any code you will add on top of that. Of course there are some specifics(e.g. avoid using long delays), but overall it just works.include <SPI.h> include <Ethernet.h> include <BlynkSimpleEthernet.h> char auth[] = "YourAuthToken"; // Find your Token in the app and paste it here void setup() { Serial.begin(9600); Blynk.begin(auth); // Here your hardware connects to Blynk Server } void loop() { Blynk.run(); // Blynk commands processing happens here //Your code goes here } // Next command gets value from the Widget in the app // which is attached and writing to Virtual Pin 1 BLYNK_WRITE(1) { incomingValue = param.asInt(); // This is the value from the Widget // You can also use: asStr() and asDouble() }We don't plan to have a web interface, because working as a UX designer for last decade in web, mobile, automotive and IoT , I definitely feel a strong trend towards mobile. And this is where we see Blynk.
We hope that Blynk will become your Magic Box in one Box :). As we add more and more widgets you might not need to design your own ones. However, I would really love to hear about your needs. What are those bits of interface you would like to use?
-
It's an interesting discussion going on here
@Gordon , it would be interesting to get your input on professional UIs and how we can enhance them in Blynk.
I would also like to point out that Blynk might seem dumb for you, because it controls things remotely, but... it also gives you full freedom and flexibility in incorporating your own code and logic. We considered Firmata at the very early stages of Blynk, but completely refused from it because it didn't suit us.@LawrenceGrif, sorry to hear about the crashes, I think that they might be caused by iOS 7.x. We already fixed it, and app will be updated this week. Please tell us about your crashes on our forum – we would be happy to investigate and help you.
Thanks.
--
Pavel
@Gordon
Yes, our documentation should be better and we are working on that. It's all about resources and time :)
However it's explained here: https://github.com/blynkkk/blynk-library/blob/master/docs/Implementing.md#virtual-pin-operations
This document is for those who want to participate in creating support for other hardware.
We also cover it in Blynk Basics doc. It will be soon on the website.
MQTT support is almost ready, but right now we are focused on user's feedback.
I agree that often it's more convenient to use desktop. Since we have all the assets and technology in place - we might build a web interface at some point and it would be pretty easy to do. It's just not the priority for us.
And yes, we have to recreate widgets for both platforms :( This is pain, but at least design assets are reused.