无法使用App Engine的远程API与Android项目 [英] Unable to use App Engine remote API with Android project

查看:186
本文介绍了无法使用App Engine的远程API与Android项目的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我试图连接到使用远程API我的本地App Engine的项目

下面是我的源:

    public class MainActivity extends Activity {

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        RemoteApiOptions options = new RemoteApiOptions()
        .server("192.168.1.5", 8888)
        .credentials("username", "password");
        RemoteApiInstaller installer = new RemoteApiInstaller();
        try {
            installer.install(options);

            DatastoreService ds = DatastoreServiceFactory.getDatastoreService();

        } catch(Exception e){
            System.err.println(e.toString());
        }finally {
            installer.uninstall();
        }
    }

    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        getMenuInflater().inflate(R.menu.activity_main, menu);
        return true;
    }
}

我进口的AppEngine-api.jar文件,AppEngine上的远程-api.jar文件,并从的 App Engine的Java SDK的

我得到以下编译错误在Eclipse和的IntelliJ:

I get the following compilation error in both Eclipse and IntelliJ:

[2012-08-23 15:16:16 - Accident Map] Dx 
UNEXPECTED TOP-LEVEL EXCEPTION:
java.lang.IllegalArgumentException: already added: Lcom/google/appengine/repackaged/com/google/common/base/Absent;
    at com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:123)
    at com.android.dx.dex.file.DexFile.add(DexFile.java:163)
    at com.android.dx.command.dexer.Main.processClass(Main.java:486)
    at com.android.dx.command.dexer.Main.processFileBytes(Main.java:455)
    at com.android.dx.command.dexer.Main.access$400(Main.java:67)
    at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:394)
    at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:245)
    at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:131)
    at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:109)
    at com.android.dx.command.dexer.Main.processOne(Main.java:418)
    at com.android.dx.command.dexer.Main.processAllFiles(Main.java:329)
    at com.android.dx.command.dexer.Main.run(Main.java:206)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.android.ide.eclipse.adt.internal.build.DexWrapper.run(DexWrapper.java:180)
    at com.android.ide.eclipse.adt.internal.build.BuildHelper.executeDx(BuildHelper.java:703)
    at com.android.ide.eclipse.adt.internal.build.builders.PostCompilerBuilder.build(PostCompilerBuilder.java:577)
    at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:321)
    at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:396)
    at org.eclipse.core.internal.resources.Project$1.run(Project.java:618)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
    at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:597)
    at org.eclipse.core.internal.resources.Project.build(Project.java:124)
    at com.android.ide.eclipse.adt.internal.project.ProjectHelper.doFullIncrementalDebugBuild(ProjectHelper.java:1000)
    at com.android.ide.eclipse.adt.internal.launch.LaunchConfigDelegate.launch(LaunchConfigDelegate.java:147)
    at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:855)
    at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:704)
    at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1047)
    at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1251)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

同样的code的工作原理进行很小的改动一个非Android的Java项目。

The same code works as a non-Android Java project with minimal changes.

推荐答案

这lookes喜欢你的AE设置是即期。我不希望是远程API来在Android手机上运行。要通过远程API连接,运行它作为一个独立的Java进程。

It lookes like your AE setup is spot on. What I wouldn't expect is for the Remote Api to run on an Android handset. To connect via the Remote API, run it as a stand alone java process.

Android的Java是不仅仅是Java的一个子集,因此远程API可以使用在Android上不可用的东西(尽管这似乎不是这里的情况),所以真的不是你的设置你的Andr​​oid项目连接到AE 在它的目的的方式。我的意思是你会怎样做,船舶您的密码连接到您的AE比如在您的APK?不会有任何访问控制做这样的说法,肯定这是不是你想要的,还是我误解你的目的。

Android java is just a subset of Java and so the remote API may use things not available on Android (though that doesn't seem the case here) So really aren't you better of setting up your Android project to connect to AE in the way it was intended. I mean what are you going to do, ship your password to connect to your AE instance in your apk? There won't be any access control doing it that way and surely that isn't what you want, or do I misunderstand your purpose.

编辑:

为什么不能在Android上运行吗?也许它可以。我看到的问题是:

Why can't it run on Android? Maybe it can. The problems I see are:

1) Android的白名单可能不包含所有需要的类远程API即使它现在,有没有保证,未来的版本将正常工作。

1) the Android Whitelist may not contain all of the classes needed by the Remote API and even if it does now, there is no guarantee that future versions will work.

2)你是硬编码密码到你的Andr​​oid应用程序。这给每一个用户的凭据做的一切......插入的垃圾,你将不得不支付是否启用计费,删除所有珍视的数据,等等,等等OK让您的用户必须是恶意的,算起来,但除非你能真正信任你的用户不要通过Play商店分发您的apk,我觉得这是人生的一个事实,即APKS获得盗版,真正质疑为什么你会给你的数据存储凭据的海盗访问。我不是说你不能这样做的,但只是指出哎,其实,也许你不知道。

2) you are hardcoding your password into your android application. this gives every user the credentials to do everything ... insert junk that you will have to pay for if billing is enabled, delete all your cherished data, etc. etc. OK so your users would have to be malicious and figure it out, but unless you can really trust your users and don't distribute your apk via the play store, I think it is a fact of life that apks get pirated and really question why you would give a pirate access to your datastore credentials. I am not saying you can't do it that way, but just pointing out hey in fact maybe you don't.

如果您使用的RPC调用(如上面的链接),你可以限制客户端能够与数据存储做什么。

If you use rpc calls (as linked above), you can limit what the client is able to do with the datastore.

这篇关于无法使用App Engine的远程API与Android项目的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆