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
Plack::Middleware(3pm)					User Contributed Perl Documentation				    Plack::Middleware(3pm)

NAME
Plack::Middleware - Base class for easy-to-use PSGI middleware SYNOPSIS
package Plack::Middleware::Foo; use parent qw( Plack::Middleware ); sub call { my($self, $env) = @_; # Do something with $env # $self->app is the original app my $res = $self->app->($env); # Do something with $res return $res; } # then in app.psgi use Plack::Builder; my $app = sub { ... } # as usual builder { enable "Plack::Middleware::Foo"; enable "Plack::Middleware::Bar", %options; $app; }; DESCRIPTION
Plack::Middleware is a utility base class to write PSGI middleware. All you have to do is to inherit from Plack::Middleware and then implement the callback "call" method (or "to_app" method that would return the PSGI code reference) to do the actual work. You can use "$self->app" to call the original (wrapped) application. Your middleware object is created at a PSGI application compile time and is persistent during the web server life cycle (unless it is a non-persistent environment such as CGI), so you should never set or cache per-request data like $env in your middleware object. See also "OBJECT LIFECYCLE" in Plack::Component. See Plack::Builder how to actually enable middleware in your .psgi application file using the DSL. If you do not like our builder DSL, you can also use "wrap" method to wrap your application with a middleware: use Plack::Middleware::Foo; my $app = sub { ... }; $app = Plack::Middleware::Foo->wrap($app, %options); $app = Plack::Middleware::Bar->wrap($app, %options); RESPONSE CALLBACK
The typical middleware is written like this: package Plack::Middleware::Something; use parent qw(Plack::Middleware); sub call { my($self, $env) = @_; # pre-processing $env my $res = $self->app->($env); # post-processing $res return $res; } The tricky thing about post processing the response is that it could either be an immediate 3 element array ref, or a code reference that implements the delayed (streaming) interface. Dealing with these two types of response in each piece of middleware is pointless, so you're recommended to use the "response_cb" wrapper function in Plack::Util when implementing a post processing middleware. my $res = $app->($env); Plack::Util::response_cb($res, sub { my $res = shift; # do something with $res; }); The callback function gets a PSGI response as a 3 element array reference, and you can update the reference to implement the post processing. package Plack::Middleware::Always500; use parent qw(Plack::Middleware); use Plack::Util; sub call { my($self, $env) = @_; my $res = $self->app->($env); Plack::Util::response_cb($res, sub { my $res = shift; $res->[0] = 500; return; }); } In this example, the callback gets the $res and updates its first element (status code) to 500. Using "response_cb" makes sure that this works with the delayed response too. You're not required (and not recommended either) to return a new array reference - they will be simply ignored. You're suggested to explicitly return, unless you fiddle with the content filter callback (see below). Similarly, note that you have to keep the $res reference when you swap the entire response. Plack::Util::response_cb($res, sub { my $res = shift; $res = [ $new_status, $new_headers, $new_body ]; # THIS DOES NOT WORK return; }); This does not work, since assigning a new anonymous array to $res doesn't update the original PSGI response value. You should instead do: Plack::Util::response_cb($res, sub { my $res = shift; @$res = ($new_status, $new_headers, $new_body); # THIS WORKS return; }); The third element of PSGI response array ref is a body, and it could be either array ref or IO::Handle-ish object. The application could also make use of $writer object if "psgi.streaming" is in effect. Dealing with these variants is again really painful, and "response_cb" can take care of that too, by allowing you to return a content filter as a code reference. # replace all "Foo" in content body with "Bar" Plack::Util::response_cb($res, sub { my $res = shift; return sub { my $chunk = shift; return unless defined $chunk; $chunk =~ s/Foo/Bar/g; return $chunk; } }); The callback takes one argument $chunk and your callback is expected to return the updated chunk. If the given $chunk is undef, it means the stream has reached the end, so your callback should also return undef, or return the final chunk and return undef when called next time. SEE ALSO
Plack Plack::Builder Plack::Component perl v5.14.2 2011-06-22 Plack::Middleware(3pm)
All times are GMT -4. The time now is 05:24 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy