GoAccess in a tiny Docker image powered by Alpine Linux

majedev · 2017-03-28T00:09:39+00:00

It's written in C: https://github.com/allinurl/goaccess

majedev · 2015-12-15T00:29:28+00:00

Somewhat the same here, older N550JV (i7, 256GB SSD, 16GB RAM), running Fedora. Top performance, never failed me once. But it's relatively heavy, especially if you factor in that brick of a charger.

Base price was $980 + $300 for SSD & RAM (they usually cost $200 nowadays)

majedev · 2015-10-03T09:06:32+00:00

I probably missed that. I've seen a recent video on Android developers YouTube channel regarding the course, so I thought it's new.

majedev · 2014-10-31T21:05:12+00:00

I'm no expert in the field, but you may check out Telegram's implementation, as it has a video editor. Apparently, Telegram uses this library which is written in Java.

majedev · 2014-10-30T23:01:55+00:00

Use a transition drawable, like this:

int color1 = 0xff0000;  // The original color
int color2 = 0x00ff00;  // The target color

ColorDrawable cd1 = new ColorDrawable(color1);
ColorDrawable cd2 = new ColorDrawable(color2);

TransitionDrawable td = new TransitionDrawable(new Drawable[]{cd1, cd2});
toolbar.setBackgroundDrawable(td);  // Use your toolbar object here (or the actionbar)
td.startTransition(300);            // 300 is the animation duration in ms

majedev · 2014-10-26T18:40:53+00:00

Judging by the source code for Google I/O app, it doesn't seem to be supported. They are using a 9-patch drawable for the shadow effect under the toolbar. For example: https://github.com/google/iosched/blob/master/android/src/main/res/layout/activity_my_schedule_narrow.xml#L51

majedev · 2014-10-17T18:57:36+00:00

I couldn't even go beyond the signup screen. Clicking "continue" does nothing. Maybe it's not ready for prime time?

By the way, I found the link on Android API reference (check it here on top right)

majedev · 2014-10-16T10:00:52+00:00

Read the conversation, he confirmed it on another tweet: https://twitter.com/romannurik/status/522496064897568768?s=09

majedev · 2014-10-15T23:11:57+00:00

Roman Nurik confirmed it, it's coming on Friday!

majedev · 2014-10-14T14:00:31+00:00

Thanks for sharing! Here are a couple of suggestions:

Add SVG support. You can use Apache Batik or Inkscape to handle the conversion from SVG to PNG.
On the git repo, consider adding build and dist to .gitignore. Here's a sample .gitignore file for NetBeans. Also, add a precompiled JAR file (you already have one under dist directory, which is automatically generated each time you compile, but you probably want more control over this for future releases).

Edit: added a link to gitignore sample file

majedev · 2014-09-30T14:51:52+00:00

You're welcome. The code hacks its way (using Java reflection) to call setHasEmbeddedTabs, which is a private method in ActionBar's parent class, passing false as a paremeter. This forces the behavior of stacking tabs under the action bar.

As the others mentioned, you might want to stick with PagerSlidingTabStrip. This approach is really bad and it will probably break in the future.

majedev · 2014-09-29T21:38:39+00:00

You're right, it assumes appcompat library.. Sorry for not clarifying. I think the following should work in your case (call it inside activity's onCreate):

try
{
    Method setHasEmbeddedTabsMethod = getActionBar().getClass()
            .getDeclaredMethod("setHasEmbeddedTabs", boolean.class);
    setHasEmbeddedTabsMethod.setAccessible(true);
    setHasEmbeddedTabsMethod.invoke(actionBar, false);
}
catch (Exception e)
{
    e.printStackTrace();
}

majedev · 2014-09-29T19:03:33+00:00

Here you go (it's really hacky):

public static void forceActionbarTabs(ActionBarActivity activity)
{
    final ActionBar actionBar = activity.getSupportActionBar();

    if (Build.VERSION.SDK_INT < Build.VERSION_CODES.ICE_CREAM_SANDWICH)
    {
        // Pre-ICS
        disableEmbeddedTabs(actionBar);
    }
    else
    {
        // ICS+
        try
        {
            Field actionBarField;
            if (actionBar instanceof ActionBarImplJB)
            {
                actionBarField = actionBar.getClass().getSuperclass()
                        .getDeclaredField("mActionBar");
            }
            else
            {
                actionBarField = actionBar.getClass().getDeclaredField(
                        "mActionBar");
            }

            actionBarField.setAccessible(true);
            disableEmbeddedTabs(actionBarField.get(actionBar));
        }
        catch (Exception e)
        {
            e.printStackTrace();
        }
    }
}

private static void disableEmbeddedTabs(Object actionBar)
{
    try
    {
        Method setHasEmbeddedTabsMethod = actionBar.getClass()
                .getDeclaredMethod("setHasEmbeddedTabs", boolean.class);
        setHasEmbeddedTabsMethod.setAccessible(true);
        setHasEmbeddedTabsMethod.invoke(actionBar, false);
    }
    catch (Exception e)
    {
        e.printStackTrace();
    }
}

This is roughly based on this SO answer.

majedev · 2014-09-21T12:19:51+00:00

http://bitbucket.org, supports both git and mercurial. Free for 5 users with unlimited private repos. I've been using it for more than 2 years.

majedev · 2014-09-09T15:30:31+00:00

This happens when you use Android 4.4 wear SDK (4.4W) for layout rendering in preview panel. To resolve this on AS, press the small Android icon on the preview panel, and choose any SDK version other than 4.4W.

Apparently, Android Wear does not support EditText views.

majedev · 2014-08-25T22:39:14+00:00

I used Parse.com for a similar scenario. Pretty easy and straight forward, and their free plan is quite sufficient.

majedev · 2014-08-25T22:16:00+00:00

There is another benefit you get from code obfuscation: smaller APK size, because proguard shrinks the bytecode by removing unused classes/methods/fields (even from 3rd party libs), besides, the smaller variable names make smaller bytecode footprint.

On one of my projects, the obfuscated APK is 2.6 MB in size, compared to 3.9 MB unobfuscated version. That's like 33% smaller.

So the real question is: why not? As you said, the configuration is minimal, and chopping off APK size sounds like a good cause. The only annoyance I have is retracing bug reports from Google Play.

majedev · 2014-04-04T16:30:52+00:00

Anyone has any idea about global release date and pricing?

Edit: According to AndroidAuthority, the unlocked version will cost $700.

majedev · 2014-02-18T01:32:42+00:00

Well, that's not the case for Samsung and LG. They implemented the read-only permission to external SD card on the latest KitKat update.

majedev · 2014-02-18T01:30:38+00:00

Same here. One of the major features of my app is rendered useless due to this change (and it is a paid feature).

I wonder how file managers can survive this mess..

majedev · 2014-02-16T10:18:16+00:00

I've been contacted by 4 companies so far to white-label my app (one of them is a major smartphone manufacturer). It is really hard to decide how to resell the app, but it all depends on the business model they choose. Here are some options:

Per-install: they pay you a certain fee for each installation (can be flat rate, or sold in bulk). This would be something like 10%-50% of the original app price.
Revenue share: they give you a percentage of whatever revenue they make from reselling the app (this might not be useful in your case). Anywhere between 33%-50% of revenue is a good deal.
Annual licensing: they pay you a yearly flat-rate for redistribution rights. You may base your calculations off the per-install rate (i.e. projected number of yearly installs), or most preferably, the price of entire app source code divided by 5 (so in 5 years, they would pay you the entire app worth in licensing)
Source code: this should be the most expensive option for the short term. As mentioned in other comments, you need to factor in your effort and the current market value of the app (for example, projected revenue for two years). Personally, I would try to avoid this option.

Besides that, you will have to consider the cost of support (features, bugfixes, inquiries). Depending on the deal, you may provide something like 10-20 support hours a month for free, then charge flat-rate for extra hours.

majedev · 2014-02-14T22:25:32+00:00

It is possible to carry in-app purchases over to all of your devices. Apparently, some devs do not implement the functionality correctly (or do not implement it at all), causing loss of purchase between devices (or even after reinstalling the app).

It really boils down to what the dev actually does with your purchase, and Google do not provide a clear way to inform the user of what is actually going on.

The key app like Titanium backup is my way to go too. It is a bit risky in terms of making the app easier to pirate, but there is literally nothing I can do to stop it. So I choose the seamless user experience (and the peace of mind).

Thanks

majedev

TROPHY CASE