Posts Tagged ‘apache’

Installing Cordova (formerly PhoneGap) with Android SDK on Gentoo

Apache Cordova is an open source framework for rapidly generating mobile apps from HTML5, CSS and JavaScript. At present, Cordova supports 7 mobile platforms with plans to expand. Since it uses core web design languages Cordova allows web developers to become mobile phone app developers without having to learn Java, C++ or the proprietary APIs of each platform.

This write-up covers the installation steps listed but not expanded on at the top of Apache Cordova API Documentation: Getting Started with Android.

To get started using Cordova on Gentoo we must first install Eclipse:

# emerge eclipse-sdk --ask

 * IMPORTANT: 9 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy "eclipse-sdk" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-util/eclipse-sdk-3.5.1-r1::gentoo (masked by: package.mask)
/usr/portage/profiles/package.mask:
# Ralph Sennhauser <sera@gentoo.org> (18 Jul 2012)
# Unmaintained, multiple vulnarabilities. #351626
# A more recent source build maintained by the community is available in the
# seden overlay. A more recent binary is available in the java-overlay.
Which is not going to be as easy as I had hoped. Emerge layman:
# emerge layman --ask

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] app-portage/layman-1.4.2-r3  USE="-bazaar -cvs -darcs -git -mercurial -subversion -test"

Once layman has been installed add the following to your make.conf:

source "/var/lib/layman/make.conf"

Java-overlay uses subversion and seden uses git; you may also want to enable the mercurial USE flag if you plan on using other overlays. We’re going to use the java-overlay since when it comes to java binary and source-compiled doesn’t really make a difference (other than a lot of time).

# layman -a java-overlay
...

You may need to add eclipse-sdk-bin to package.keywords before it can be emerged:

# echo "dev-util/eclipse-sdk-bin" >> /etc/portage/package.keywords

Now install the package:

# emerge eclipse-sdk-bin

Now we need to install the :

$ wget http://dl.google.com/android/android-sdk_r20.0.3-linux.tgz
$ tar xvf android-sdk_r20.0.3-linux.tgz
$ android-sdk-linux/tools/android

Running “android” from the command line in the tools directory will bring up the Android SDK Manager in X windows. Select any additional packages you would like to install and hit the Install button.

Now we’ll download the latest version of the Android Development Tools plugin for eclipse at http://developer.android.com/tools/sdk/eclipse-adt.html. Start eclipse:

$ eclipse-bin-4.2

Now follow the installation guide at http://developer.android.com/sdk/installing/installing-adt.html:

  1. Start Eclipse, then select Help > Install New Software.
  2. Click Add, in the top-right corner.
  3. In the Add Repository dialog that appears, enter “ADT Plugin” for the Name and the following URL for the Location:

    https://dl-ssl.google.com/android/eclipse/

  4. Click OK.

    If you have trouble acquiring the plugin, try using “http” in the Location URL, instead of “https” (https is preferred for security reasons).

  5. In the Available Software dialog, select the checkbox next to Developer Tools and click Next.
  6. In the next window, you’ll see a list of the tools to be downloaded. Click Next.
  7. Read and accept the license agreements, then click Finish.

    If you get a security warning saying that the authenticity or validity of the software can’t be established, click OK.

  8. When the installation completes, restart Eclipse.

After restarting Eclipse you will be presented with the Welcome to Android Development dialogue, install the new SDK, and optionally 2.2. You are now ready to proceed with the rest of the Getting Started guide.

Reliable AJAX: Timeout and Retry XMLHttpRequest

A lot of AJAX seems to rely on ideal conditions: a server that is both running and in good health, a reliable high speed internet connection, a lack of packet loss etc. Unfortunately, this is not always the case – what happens when your user triggers an event and the daemon is restarting or they are hopping access points/cell towers? What happens if the server load is sky high and only half of the requests are getting through? AJAX isn’t a very robust technology but we can increase the odds of our XMLHttpRequest transactions succeeding with some rudimentary JavaScript.

Newer Msxml XMLHTTP implementations support runtime-definable connection time-outs but that covers at best half of your audience and is therefore irrelevant to our needs. We will be implementing our own cross-browser compatible time-outs with the setTimeout() function. Once the time-out expires we will kill the XHR and repeat the process again, with a slightly longer time-out. The process is repeated as many times as necessary; each time increasing the duration. This is called backoff – similar in concept to but much less complicated than the exponential backoff algorithm Ethernet uses to recover from packet collisions.

The tricky part is to set the initial time-out to a value which gives the browser as long as reasonably possible to send and receive the request under strained conditions. Depending on how long the round trip takes in ideal circumstances a safe value can range anywhere from (plus) less than one second to several seconds – this is going to be unique to your application, resources and network so test thoroughly. If the time-out is too low we will be doing more harm than good by stopping and re-sending the request before it has even had a chance to complete. It might be sensible for you to give the last attempt a huge time-out.

The other major factor to consider is whether “the user knows best” in the given situation or not. If you are giving a visual cue to the user that there is AJAX activity happening in the background or if they expect to see something on the page update once the request has completed they might notice that things are taking a little long to react and re-trigger the event (read: hammer on the button like a mindless idiot). If you don’t want them to interfere with the time-out and re-send procedure take that into account when setting up your trigger – the example we are going to use assumes the user knows best. If they hammer on the button the best case scenario is their request goes through faster than if they left it alone and the worst case scenario is once they stop hammering the time-out and re-load cycle will run its course from the top anyway.

// Initialize global variables
var attempts = 0;
var timeout = 1000;    // In miliseconds
var max_attempts = 5;  // Six from 0
var script_url = ''    // The location of the target processing script
var junk = '';         // The variables we're POSTing, probably set in trigger()
var t = '';

// Cross-Browser XMLHttpRequest()
function createXHR()
{
	try { return new XMLHttpRequest(); } catch(e) {}
	try { return new ActiveXObject("Msxml2.XMLHTTP.7.0"); } catch (e) {}
	try { return new ActiveXObject("Msxml2.XMLHTTP.6.0"); } catch (e) {}
	try { return new ActiveXObject("Msxml2.XMLHTTP.5.0"); } catch (e) {}
	try { return new ActiveXObject("Msxml2.XMLHTTP.4.0"); } catch (e) {}
	try { return new ActiveXObject("Msxml2.XMLHTTP.3.0"); } catch (e) {}
	try { return new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) {}
	try { return new ActiveXObject("Microsoft.XMLHTTP"); } catch (e) {}
	alert("Please enable ActiveX or update your browser.");
	return null;
}

// User calls this function, i.e. onclick event handler
function trigger()
{	
	// Re-set the time-out in case the user interrupts the cycle
	clearTimeout(t);
	attempts = 0;
	timeout = 1000;

	driver();
}

// Handle the state changes of the XHR
function callback()
{
	if (xmlhttp.readyState==4 && xmlhttp.status==200)
	{
		// Success! Re-set the time-out for the next round.
		clearTimeout(t);
		attempts = 0;
		timeout = 1000;

		xmlhttp = '';

		// Perform whatever action we need to do on success.
	}
	else
	{
		// Error handling/Request status indication
	}
}

// The guts of the request
function driver()
{
	xmlhttp = createXHR();

	xmlhttp.open("POST",script_url,true);

	t = setTimeout(function(){timedout();}, timeout);
	xmlhttp.onreadystatechange=function(){callback();}

	xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");
	xmlhttp.send(junk);
}

// Run this if we time out
function timedout()
{
	if(typeof(xmlhttp) == 'object')
		xmlhttp.abort();

	if(attempts < max_attempts)
	{
		// We timed out. Back off the time-out a bit.
		attempts++;
		timeout = timeout + 200;
		// We're adding 200ms to the timeout each iteration, YMMV.
		// Maybe if attempts == max_attempts make the timeout really huge.

		// Play it again, Sam!
		driver();
	}
	else
	{
		// We failed. Set the timeout back to default for the next round.
		timeout = 1000;
		attempts = 0;
		xmlhttp = '';
		alert("Timed out while sending request to server.");
	}
}

Apache Reload: Fix seg fault or similar nasty error detected in the parent process

I noticed this nasty wee bugger last week:

[notice] seg fault or similar nasty error detected in the parent process

The first time it happened the drop in traffic did not correlate with the daily init scripts but when the second occurance this morning did I finally had somewhere to start. The default logrotate script for apache on gentoo (and many other flavours) does a graceful reload once the log files have been rotated to release their inodes. Now I could reproduce the issue:

# /etc/init.d/apache2 reload
 * Gracefully restarting apache2 ...
# /etc/init.d/apache2 restart
 * Stopping apache2 ...
httpd (pid 2505?) not running                                                [ ok ]
 * Starting apache2 ...
 * start-stop-daemon: /usr/sbin/apache2 is already running
# /etc/init.d/apache2 stop   
 * Stopping apache2 ...
httpd (pid 2505?) not running
# /etc/init.d/apache2 start
 * Starting apache2 ...
 * start-stop-daemon: /usr/sbin/apache2 is already running

Poking around this seems to usually be caused by loading bad/wrong/nonexistent libraries in the php.ini – and I am guilty of carrying over old php.inis on upgrade. Updating and switching to the distributed php.ini for my installed version of php seems to have solved this issue.

Sometimes it really is my fault :p

Return top
foxpa.ws
Online Marketing Toplist
Internet
Technology Blogs - Blog Rankings

Internet Blogs - BlogCatalog Blog Directory

Bad Karma Networks

Please Donate!


Made in Canada  •  There's a fox in the Gibson!  •  2010-12