Sponsored Content
Top Forums Programming Wuhan Coronavirus Status App for China - Rapid Prototype using MQTT and the IoT OnOff IOS App Post 303043644 by Neo on Sunday 2nd of February 2020 11:37:14 PM
Old 02-03-2020
The IoT OnOff app needs to be configured to receive live update messages from the server.

It works the best when the IP address is used (not the name of the site, it needs the IP to work reliably).

If anyone wants to run this app, please post back and I will guide you step-by-step.

Wuhan Coronavirus Status App for China - Rapid Prototype using MQTT and the IoT OnOff IOS App-img_a3fe5be2401b-1jpeg
 

5 More Discussions You Might Find Interesting

1. Solaris

luminis app

The guys at SunGard want to charge a lot of $$$$ for installing Luminis and we are trying to see if this can be done without them. Their installation guide provided page #53 ( http://www.luminis.nocccd.edu/documents/Luminis%20IV/lp40000in.pdf ) doesn't really tell you much. All they say is that... (4 Replies)
Discussion started by: ceci1
4 Replies

2. Solaris

Problem with /app

Hi folks, i have a problem with my /app directory on solaris 10.It is mounted under rpool root and sometimes it increase dimension bringing root out of space.I want to mount /app under different position, maybe under secondary hardisk for which i have created a mount point with zfs pool...How... (10 Replies)
Discussion started by: mattpunk
10 Replies

3. OS X (Apple)

Can a ios app be developed on a windows or ipad?

hi, i want to start developing an ios app that can be used on iphone and ipad. can anyone guide me how to start? i saw that it can be developed only on a mac system.. but i dont have a mac system. i have an ipad 4 and a laptop with windows os? can i use one of these to start developing ios app??... (4 Replies)
Discussion started by: Little
4 Replies

4. Programming

Arduino Project: iPhone to HM-10 BLE to NB-IoT Shield to NB-IoT Network to Internet to Linux Server

This post describes a "work in progress" project I started today. Here is the High Level Overview: Currently, this project sits on my desk as an Arduino UNO (on the bottom), an NB-IoT Shield (sandwiched in the middle), a Sensor Shield (on top) with a HM-10 BLE Module (in the little... (13 Replies)
Discussion started by: Neo
13 Replies

5. Programming

Wuhan Coronavirus Status for China - Rapid Prototype Blynk App with ESP8266

Here is a rapid prototype app I just put together which might be of interest to some people. Basically, I have parsed the data from a Chinese web site which is tracking the Wuhan coronavirus, and cache that data every minute via a local cron file and make a simple API available to a Blink app. ... (6 Replies)
Discussion started by: Neo
6 Replies
SDL::Tutorial::Animation(3)				User Contributed Perl Documentation			       SDL::Tutorial::Animation(3)

NAME
SDL::Tutorial::Animation SYNOPSIS
# to read this tutorial $ perldoc SDL::Tutorial::Animation # to create a demo animation program based on this tutorial $ perl -MSDL::Tutorial::Animation=sdl_anim.pl -e 1 ANIMATING A RECTANGLE
Now that you can display a rectangle on the screen, the next step is to animate that rectangle. As with movies, there's no actual motion. Computer animations are just very very fast slideshows. The hard work is creating nearly identical images in every slide (or frame, in graphics terms). Okay, it's not that difficult. There is one small difficulty to address, however. Once you blit one surface onto another, the destination is changed permanently. There's no concept of layers here unless you write it yourself. If you fail to take this into account (and just about everyone does at first), you'll end up with blurry graphics moving around on the screen. There are two approaches to solve this problem, redrawing the screen on every frame and saving and restoring the background for every object drawn. Redrawing the Screen Since you have to draw the screen in the right order once to start with it's pretty easy to make this into a loop and redraw things in the right order for every frame. Given a SDL::App object $app, a SDL::Rect $rect, and a SDL::Color $color, you only have to create a new SDL::Rect $bg, representing the whole of the background surface and a new SDL::Color $bg_color, representing the background color. You can write a "draw_frame()" function as follows: sub draw_frame { my ($app, %args) = @_; $app->fill( $args{ bg }, $args{ bg_color } ); $app->fill( $args{rect}, $args{rect_color} ); $app->update( $args{bg} ); } Since you can change the "x" and "y" coordinates of a rect with the "x()" and "y()" methods, you can move a rectangle across the screen with a loop like this: for my $x (0 .. 640) { $rect->x( $x ); draw_frame( $app, bg => $bg, bg_color => $bg_color, rect => $rect, rect_color => $color, ); } If $rect's starting y position is 190 and its height and width are 100, the rectangle (er, square) will move across the middle of the screen. Provided you can keep track of the proper order in which to redraw rectangles and provided you don't need the optimal speed necessary (since blitting every object takes more work than just blitting the portions you need), this works quite well. Undrawing the Updated Rectangle If you need more speed or want to make a different complexity tradeoff, you can take a snapshot of the destination rectangle before you blit onto it. That way, when you need to redraw, you can blit the old snapshot back before blitting to the new position. Note: I have no idea how this will work in the face of alpha blending, which, admittedly, I haven't even mentioned yet. If you don't know what this means, forget it. If you do know what this means and know why I'm waving my hands here, feel free to explain what should and what does happen and why. :) With this technique, the frame-drawing subroutine has to be a little more complicated. Instead of the background rect, it needs a rect for the previous position. It also needs to do two updates (or must perform some scary math to figure out the rectangle of the correct size to "update()". No thanks!). sub undraw_redraw_rect { my ($app, %args) = @_; $app->fill( $args{old_rect}, $args{bg_color} ); $app->fill( $args{rect], $args{rect_color} ); $app->update( $args{old_rect}, $args{rect} ); } We'll need to create a new SDL::Rect, $old_rect, that is a duplicate of $rect, at the same position at first. You should already know how to do this. As before, the loop to call "undraw_redraw_rect()" would look something like: for my $x (0 .. 640) { $rect->x( $x ); undraw_redraw_rect( $app, rect => $rect, old_rect => $old_rect, rect_color => $color, bg_color => $bgcolor, ); $old_rect->x( $x ); } If you run this code, you'll probably notice that it's tremendously faster than the previous version. It may be too fast, where the alternate technique was just fast enough. There are a couple of good ways to set a fixed animation speed regardless of the speed of the processor and graphics hardware (provided they're good enough, which is increasingly often the case), and we'll get to them soon. SEE ALSO
SDL::Tutorial::Drawing basic drawing with SDL Perl SDL::Tutorial::Images animating images AUTHOR
chromatic, <chromatic@wgz.org> Written for and maintained by the Perl SDL project, <http://sdl.perl.org/>. BUGS
No known bugs. COPYRIGHT
Copyright (c) 2003 - 2004, chromatic. All rights reserved. This module is distributed under the same terms as Perl itself, in the hope that it is useful but certainly under no guarantee. perl v5.12.1 2010-07-05 SDL::Tutorial::Animation(3)
All times are GMT -4. The time now is 03:58 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy