Skip to content
This repository has been archived by the owner on Apr 3, 2020. It is now read-only.

Dead link on Setup-Development-Environment-Of-Crosswalk-Cordova-Android #118

Open
wants to merge 62 commits into
base: master
Choose a base branch
from

Conversation

dotnetwise
Copy link

No description provided.

infil00p and others added 30 commits May 6, 2014 15:51
The plain Cordova app is able to run.

TODO:
1. Plugin
2. Unit testing
This fixes the issue that Geolocation plugin does not work.
In XWalk, the thread which ExposedJsApi.exec() runs in does not contain
a message loop. As android.location.LocationManager need a loop to
process message, we have to prepare a Looper manually.
The root cause is the File Transfer API implementation leverages the android.webkit.CookieManager.
But trying to getinstance() of CookieManager before the webview isn't instantiated would cause crash.
In the cordova with xwalk backend solution, there doesn't exist webview.

According to android official document:
http://developer.android.com/reference/android/webkit/CookieManager.html#getInstance%28%29
We need to call "CookieSyncManager.createInstance(Context)" first.

Known issue:
This only fix crash issue, the cookie support is faking.
Still need to bridge xwalk cookie manager with default android.webkit.CookieManager.

BUG=https://github.com/otcshare/cordova-xwalk-android/issues/13
It needs to hook activity life-cycle events (resume, pause, destory and
on activityresult) to XWalkView handlers. Otherwise, it causes black screen
when pause-resume cycles for apps.

BUG=https://github.com/otcshare/cordova-xwalk-android/issues/55
Enable them since XWalkView has the APIs.
Changes in this patch:
 1. Implement XWalkRuntimeViewProvider interface for CordovaWebView.
 2. Add a public class CordovaXWalkCoreExtensionBridge to provide the
    functionalities of friendly class XWalkCoreExtensionBridge.
Otherwise, buildbot will not pack it into tarball.
Otherwise, build is blocked for abstract function not implemented.
It is introduced in XWalkRuntimeViewProvider to destroy the native
resources occupied by extension.
This is a refactor to remove unnecessary interfaces exposed by
XWalkRuntimeViewProvider. Reusing XWalkExtensionManager is enough to
integrate the extension system into cordova container.
XWalk adds the onGeolocationPermissionsShowPrompt support. Change the
CordovaWebView's implemenation to that.
XWalk adds the copyBackForwardList/saveState/restoreState API support,
and also adds WebBackForwardList and WebHistoryItem class.
Change the CordovaWebView's implemenation to that.
It includes:
1. update the project wiki URL.
2. add the python 2.6 into the requires.
Now the "create" script will not compile a cordova.jar,
insteadly, it will setup dependency for newly created
project.

Currently, the script will assume xwalk_core_library is
placed aside of cordova-xwalk-android.

TODO:
1. if core library not found, the "create" script should
download it.
2. Enable create.bat script on Windows.

Usage:
Assumpt the working folder is at /home/me/cordova
1. mkdir /home/me/cordova
2. cd /home/me/cordova
3. git clone ssh://[email protected]/otcshare/cordova-xwalk-android.git
4. download xwalk_core_library.tar.gz from xwalk release and extract it at
   /home/me/cordova/xwalk_core_library.
   (If the build you pick doesn't include
    crosswalk-project/crosswalk#847, you need to
    manually update the build.xml in xwalk_core_library to work)
5. cd cordova-xwalk-android
6. ./bin/create ../hello your.package.name YourAppName
7. cd ../hello
8. ant release/debug
   (you probably need to create you keystore first for release)

BUG=https://github.com/otcshare/cordova-xwalk-android/issues/19
Android library project doesn't handle assets according to
http://developer.android.com/tools/projects/index.html.

BUG=Input tag crashes cordova app
It aims to optimize the CLI workflow. It requires the buildbot copies the
xwalk_core_library into framework when producing cordova.tar.gz.

With these changes, CLI users will not download xwalk_core_library separately.
junmin-zhu and others added 24 commits June 6, 2014 23:48
"robotium", which heavily relys on the Android WebView.
So disable it for XWalkView.
Add ErrorCodeConvertor for XWalk backend, because its error code is
different with Cordova error code.
The implementation in xwalk is in XWalkDefaultWebChromeClient, however
CordovaChromeClient extends XWalkWebChromeClient which barely has
real implementation. That causes many features missing in cordova
container.

BUG=https://crosswalk-project.org/jira/browse/XWALK-954
In fullscreen mode, back key is used to exit fullscreen
prior to navigation.
The overall back key handling priority is:
1. Exit fullscreen
2. Exit video
3. Let JS handle
4. Go backward
5. Finish activity.
…alkView

onNewIntent in XWalkView is introduced by Notification API, it needs
return boolean to identify the intent is consumed or not.

BUG=https://crosswalk-project.org/jira/browse/XWALK-1072
…ibrary.

Crosswalk core library is changed and the extension mechanism/implementation
now is inside of core library. No need to call extension manager anymore.

Besides, onPause/onResume/onDestroy functions are called in CordovaWebView.
It's because we don't only pause/resume timers but also need to pause/resume
video playback, popup dialog and others. All of these are handled in above
functions.
It's not needed anymore, assets from xwalk_core_library
have been moved to res/raw.
XWalkDefaultWebChromeClient is moved from org.xwalk.core.client to
org.xwalk.core. Change the package name in Cordova as well.

BUG=https://crosswalk-project.org/jira/browse/XWALK-1227
The parameters of XWalkClient.onReceivedSslError are changed due to
a new fix. Change it as well here to pass the compilation.

BUG=https://crosswalk-project.org/jira/browse/XWALK-1287
SSLErrorHandler was removed in crosswalk so there is no need to
import it in Cordova.

BUG=https://crosswalk-project.org/jira/browse/XWALK-1287
Crosswalk defines the new embedding API which is public to external users.
Migrate Cordova container to use the new API. Due to some legacy issues,
there are still some remaining dependencies in Cordova on Crosswalk internal
classes, including XWalkSettings, XWalkClient, XWalkWebChromeClient and
XWalkHttpAuthHandler.
Next is to figure out how to remove above dependencies.

BUG=https://crosswalk-project.org/jira/browse/XWALK-1375
Both 2 classes are removed out of Crosswalk core library. Use
the public classes XWalkUIClient and XWalkResourceClient.

BUG=https://crosswalk-project.org/jira/browse/XWALK-1481
XWalk Core library will auto detect network status, and below two permissions are needed:
  android.permission.ACCESS_NETWORK_STATE
  android.permission.ACCESS_WIFI_STATE
Add these two permissions to AndroidManifest.xml

BUG=XWALK-1480
The root cause is when using custom_rules.xml, R.java of
xwalk_core_library is not generated.

TODO: need to discuss with upstream when integrating Crosswalk
In some cases, XWalkView will fail to initialize, e.g. CPU
architecture mismatch detected. Need to check null pointer
to keep Cordova App from crash in such case.

BUG=https://crosswalk-project.org/jira/browse/XWALK-1616
Developer will provide two splash screen images for landscape and portrait mode.
Currently it will auto stretch the splash screen layout when orientation changed.
This fix can change the layout as developer needed for different orientations.

BUG=XWALK-1810
Rebase crosswalk Cordova container to 3.5.0.
…Client

onPageStarted/Finished are methods of XWalkClient which is internal class.
For subclass of CordovaWebViewClient usage, We need to route them out.

BUG=https://crosswalk-project.org/jira/browse/XWALK-1882
…rted

Fix onPageStarted/Finished never called in subclass of CordovaWebViewCl...
@huningxin
Copy link
Contributor

Thanks for reporting this. You can always file a bug in https://crosswalk-project.org/jira. I go ahead to file a bug first as https://crosswalk-project.org/jira/browse/XWALK-1938. I will fix that soon.

@dotnetwise
Copy link
Author

I know there are some old-fashioned guys, and for good reason, are still using JIRA :)
However, Github in general, and Github issues in special are way much better / easier to post / track / follow / understand / reference etc.
I'm sure you know what I mean :)

In the mean time, thank you for filling in a bug on JIRA and taking care of it.

Perhaps enabling both github issues as well?
One option could be keeping them in a sync?

@huningxin
Copy link
Contributor

Thanks for suggesting using github issues. I believe there are reasons the crosswalk-project is using JIRA. I suggest you can raise this request and discuss with crosswalk developers in crosswalk-dev mailing list. WDYT?

@dotnetwise
Copy link
Author

Mailing list? and IRC channels. Sounds like talking to one of these
224598kaipqc3wg 1

:)

@darktears
Copy link

@dotnetwise : we use IRC for direct communication and mailing lists for obvious reasons as possibility to archive publicly and also because mail are easy to send. I guess this is pretty standard and efficient way to communicate. You may think it's backward however it works well for us.

We don't use the Github issues because it was a deliberate choice. We used them in the past and found them too "basic" for what we needed. We ran them for few months and decided to move to something else (for example you can't make issues "private").

@townxelliot : can you have a look please?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants