① android 为什么采用intent 进行数据交互
Android系统的一个重要特性就是一个应用程序可以调用另外一个应用程序来完成用户的请求动作。比如你的应用程序需要给用户显示一个地理位置在地图上,你不必在你的应用程序中实现地图功能,而是创建一个显示这个地理位置的Intent,发送出去,Android系统会启动那些可以处理这个请求的应用程序。还比如:你用网络云盘下载了一个pdf文档,你在点击打开这个文档的时候网络云盘是无法打开的,但是也许你系统上安装有其他的能打开pdf文档的阅读器,这个时候就会弹出一个对话框,列举了可以打开pdf文档的应用程序,你可以自由选择一个应用程序打开你下载的文档。
使用隐式Intent:
隐式Intent不会指明要启动的组件名称,而是声明执行的动作,动作指定了你想要做什么事情,比如显示(view),编辑(edit),发送(send),获取一些东西(get something)等。Intent经常会附带一些数据,比如你要查看的地址,发送邮件的内容等。数据形式依赖于你想要做什么事情,数据可以是一个Uri,也可以是其他数据类型(基本数据类型或者对象)之一。数据不是必须的,你的Intent中可以不包含data。
② android 菜鸟问题。如何监听某应用当前正在与用户交互
你获取 系统的ActivityManager 的对象 有一个函数 是获取最近activity 其中第一个就是正在交互的应用的包名
③ 在交互细节上,Android 与 iOS 有哪些区别
在交互细节上有哪些区别,这问题回答起来估计就有难度了!
事先声明,文长...... -_-'首先从导航模式开始,iOS 应用大多数情况,只提供单一的路径。无论什么样的程序,都只有一个窗口,这个窗口用于放置程序的内容和功能,用户不会意识到这个窗口。在 iOS 设备中,用户觉得程序就是依次呈现的一屏又一屏图像。
可以把一屏图像想象成一个离散的视觉状态或者模态。一个程序拥有的屏数或多或少,每一屏都是各种素材和控件的组合,由此而衍生了iOS 应用内的多种导航模式,如:平铺、列表及树状等。涉及到层级导航通过应用内左上角back键进行返回操作(图1)。图1
图20
Android的Tab栏用于探索和切换不同视图或功能,也可用于浏览不同分类的内容集合。主要有三种tab类型:
1. 滚动tab
2. 固定tab
3. 堆叠tab
两个系统还有很多细节上的不同,像Android的边界反馈效果与iOS的回拉效果、Activity Indicator的对比、dialog上确认键两个系统分别在不同的位置等,以及iOS特有功能上的一些交互特性Passbook、iCloud、iAd等等......
根据android4,0规范与IOS规范,android与IOS主要的不容之处表现在:
1.android4.0包括三个虚拟按键:返回、home和最近任务,而IOS只有一个物理Home按键,返回按钮一般放置在导航栏左上方
2.android的主要操作栏在屏幕上方包括:向上+图标+页面名称+主要操作+更多(次要操作),主要操作栏还提供视图切换功能。IOS包括导航栏、工具栏、tab栏,导航栏包括返回+标题+主要操作,工具栏包括一些次要操作,Tab栏承担页面视图切换的功能。
④ 如何搭建一个与Android客户端交互的服务器
android客户端和服务器端是基于IntentService的,具体如下:
后台使用简单的servlet,支持GET或POST。这个servlet最终返回给前台一个字符串flag,值是true或false,表示登录是否成功。
然后在安卓的ADT上创建一个安卓项目,建立两个Activity,分别作为登录界面和登录成功界面。
HTTP的访问公共类,用于处理GET和POST请求。
IntentService服务,用于在后台以队列方式处理耗时操作。
在AndroidManifest.xml中注册IntentService。注意uses-permission节点,为程序开启访问网络的权限。
登陆界面处理,注意按钮监听事件中,使用Intent将要传递的值传给service。接收广播类中,同样使用Intent将要传递的值传给下一个Activity。在onCreate()中,动态注册接收广播类的实例receiver。在接收广播类中,不要使用完毕后忘记注销接收器,否则会报一个Are you missing a call to unregisterReceiver()? 的异常。
⑤ android客户端怎么与服务器交互
1、java服务器建立至少一种服务webservices、servlet、socket
2、客户端通过socket或者httpurlconnection的方式进行连接访问
服务端:
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
// TODO Auto-generated method stub
resp.setContentType("text/html;charset=utf-8");
req.setCharacterEncoding("utf-8");
resp.setCharacterEncoding("utf-8");
PrintWriter out = resp.getWriter();
//用HTML格式给浏览器返回数据
out.println("<html>");
out.println("<head>");
out.println("<title>Tomcat Servlet测试</title>");
out.println("</head>");
out.println("<body>");
out.println("Hello,First Servlet!");
out.println("</body>");
out.println("</html>");
out.println("Hello,第一个Tomcat!!!");
out.close();
}
客户端:
private String doGet(String url){
String responseStr = "";
try {
String name = nameEdit.getText().toString().trim();
String code = codeEdit.getText().toString().trim();
String getUrl = URL + "?NAME=" + name+"&"+"CODE=" + code;
HttpGet httpRequest = new HttpGet(getUrl);
HttpParams params = new BasicHttpParams();
ConnManagerParams.setTimeout(params, 1000);
HttpConnectionParams.setConnectionTimeout(params, 3000);
HttpConnectionParams.setSoTimeout(params, 5000);
httpRequest.setParams(params);
HttpResponse httpResponse = new DefaultHttpClient().execute(httpRequest);
final int ret = httpResponse.getStatusLine().getStatusCode();
if(ret == HttpStatus.SC_OK){
responseStr = EntityUtils.toString(httpResponse.getEntity(), HTTP.UTF_8);
}else{
responseStr = "-1";
}
} catch (ClientProtocolException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return responseStr;
}
⑥ android平台的app 手机客户端和后台服务器怎么进行数据交互的
首先不要管安卓端还是苹果端,现在一般都是响应式的app,你放到安卓或者苹果或者pc或者平板都是没有问题的。一般采用的是http接口通讯,或者socket连接。具体你要去查资料找Demo了。而且现在主流是采用html5开发或者混合开发了。所以最好是服务器提供appAPI接口,通过http访问服务器,获取数据,数据一般是json,或者xml,拿到后解析数据就可以了,然后再用UI框架或者其他框架或者自定义的UI封装下格式很漂亮了,至于cookie和session等,看你的习惯,网络验证和签名那些也自己看习惯,如果涉及到大数据,还需要引入第三方框架的,直接引入就可以了,不过推荐自己写,防止侵权。都是很通用的。
⑦ android 和 ios 人机交互设计指南中最重要的几点是什么
android 和 ios 人机交互设计指南中最重要的几点告诉你,希望你能理解:
这是针对于处于开发中的API或技术的初步文档。虽然该文档在技术精确度上经过了严格的审核,但并非最终版本,仅供苹果开发者计划的注册会员使用。苹果提供这份机要文档的目的,是帮助你按照文中描述的方式对技术的选择及界面的设计开发进行规划。这些信息有可能发生变化,届时,你的设计开发方式需要基于最终版本的操作系统及文档进行相应的调整和测试。该文档或许会随着未来API或相关技术在的发展而进行更新。
审美的完整性
对app而言,审美的完整性并不是用来衡量app漂亮与否,或者塑造它的风格。而是通过app的外观、交互行为和功能共同传递一致的,清晰明了的信息。
用户关注app能否兑现此前承诺的功能,但是app的外观和交互行为也潜在地影响着用户。比如,一款帮用户处理严肃任务的app,可通过使用标准控件或可预见的交互方式让装饰性元素更为精妙和无打扰,从而让用户把注意力集中在对任务的处理上。
App清楚明了地把使用目的传达给了用户,这可以让用户更加信任它。不过,如果开发者通过入侵性的,轻佻的或者武断的UI向用户传递了混乱的信息,则用户可能会质疑app的可靠性和可信赖度。
另一方面,对一款鼓励沉浸式任务的的app,比如游戏,用户期待一个迷人的外观,和有趣、刺激以及鼓舞人心的发现。用户并不期望在游戏中完成一系列严肃性的或者生产性的任务,但他们期望游戏的外观和交互方式可以与游戏目的很好地融合在一起。
App需保持一致性
这样方便用户积累的知识和技巧在app各部分UI之间,在app之间进行迁移。一致性并不是盲目模仿其他app,也不是停滞不前,而是更关注用户熟悉的标准和范例。
决定你的iOS app是否要遵守一致性的原则,考虑下边几个问题:
1.你的app是否符合iOS的标准?App 正确使用系统提供的控件、视图以及图标了吗?App以可靠方式整合设备的功能了吗?
2.App自身是否一致?文本有没有使用统一的术语和风格?相同图标代表的意义是否一致?用户在不同地方执行了相同的操作,用户能否预测到将会发生什么样的结果?贯穿App的自定义UI元素的外观和交互方式是否一致?
3.App现在的版本与此前的版本是否一致?条款和意义是否一致?App的基本概念和主要功能本质上有没有发生变化?
直接操作
直接在屏幕上操作对象,而不使用单独的控件来操作,这样用户会更专注于当前的任务,他们也更容易理解操作产生的结果。
使用Multi-Touch 界面,用户可通过双指张开或者闭合来放大或者缩小图片和内容区域。在游戏中,玩家可以直接移动屏幕上的对象或者与对象进行直接的交互。 在一款iOS app中,以下动作可为用户提供直接操作的体验:
1.旋转或者移动设备以影响屏幕上的效果
2.使用手势直接操控屏幕上的对象
3.可看到动作产生的直接结果或可视化结果
反馈
反馈是对用户动作的承认,向他们展示操作的结果,更新他们任务的进程。内置iOS app为每位用户的动作提供了可觉察的反馈。在用户执行点击操作的过程中,列表项目和控件会持续几秒钟高亮状态,通过控件所处状态短暂的改变来显示进程的变化。
精巧的动画可以给用户有意义的反馈,可帮助用户清楚地知晓动作产生的结果。比如,列表可以动态地展示新增一行的操作,从而帮助用户跟踪视觉上的变化。
声音也可以给用户有用的反馈,但不应该是仅有的反馈机制,因为用户不能时刻倾听他们的设备发出了什么样的声音来反馈执行的动作。
隐喻
如果app中虚拟的对象和动作象征着熟悉的用户体验,那么不管这些体验是深植于真实世界还是数字世界,用户都可以快速掌握app的使用方法。在隐喻不涉及对象或动作局限性的情况下,App使用隐喻来暗示用法或者体验再好不过。
由于用户真实地与屏幕进行交互,因此iOS app的隐喻空间非常广阔。iOS 中的隐喻包括:
1.移动分层的视图来展现其下面的内容
2.在游戏中拖动、滑动或者轻扫对象
3.点击开关,滑动滑块以及旋转选择器
4.在杂志或书上进行翻页
用户控制
用户应该发起和控制动作,而不是app。一款app可以启发用户的动作行为方法,或者提醒用户危险后果,但是app撇开用户做决策是错误的。app能给用户他们想要的能力,也能帮他们规避不想要的结果,最好的app应该能在这两者之间正确地平衡。
当交互行为和控件是熟悉的,可预见的时候,用户对app会更有控制感。当交互动作简单直接的时候,用户对app的动作也更容易理解和记忆。用户期望在操作产生结果前有足够多的机会来取消它们,并且他们期望有机会确认自己的目的,从而执行一个具有潜在破坏性的动作。最后,用户期望能优雅地停止正在进行的操作。
⑧ android客户端和服务器端怎么交互
android客户端和服务器端是基于IntentService的,具体如下:
后台使用简单的servlet,支持GET或POST。这个servlet最终返回给前台一个字符串flag,值是true或false,表示登录是否成功。
然后在安卓的ADT上创建一个安卓项目,建立两个Activity,分别作为登录界面和登录成功界面。
HTTP的访问公共类,用于处理GET和POST请求。
IntentService服务,用于在后台以队列方式处理耗时操作。
在AndroidManifest.xml中注册IntentService。注意uses-permission节点,为程序开启访问网络的权限。
登陆界面处理,注意按钮监听事件中,使用Intent将要传递的值传给service。接收广播类中,同样使用Intent将要传递的值传给下一个Activity。在onCreate()中,动态注册接收广播类的实例receiver。在接收广播类中,不要使用完毕后忘记注销接收器,否则会报一个Are you missing a call to unregisterReceiver()? 的异常。
⑨ android,ios在人机交互方面各有什么特点
iOS:
- 非常完善的 HIG,界面风格和交互方式比较统一,一般应用对于大部分用户来说都能够凭直觉上手使用;
- 非常注重细节,比如如果界面上输入焦点自动进入输入框会弹出键盘(Android上要人点击才会触发键盘),这种地方很多;
- 后台的多任务处理在用户体验和续航之间达成了相当好的平衡,基本用户可以放心的去用,不用考虑应用后台前台的问题;
- 高质量应用数量多,同一个服务如果在不同移动平台上各有应用,那么 iOS 的版本多半是最好的(至少是同样好的);
Android:
- Notification 系统界面比 iOS 好;
- 支持自定义桌面,能满足部分用户的个性化需要;
- 支持模拟器应用,在 Android 平台上玩老游戏不错 >_< ;
- 支持第三方输入法,对中文输入提升较大;
- 大多数 Google 自己的应用的用户体验都不错。
⑩ android音乐播放器怎么实现用户交互
首先实现一个Service类,我们命名之为MainService,那么我们应该如何启动这个Service呢?启动Service一个Service有两种方法:一种是startService (Intent);另外一种是:bindService (Intent);
第一种启动方式,适用于Service独立完成任务,例如说一个下载,如果不需要暂停或者取消的话,可以这样来做。但是,我们这是音乐播放应用,把MediaPlayer放在Service中执行播放,这样的方式很难有暂停等交互。(其实也可以这样做,例如每次交互操作都用startService来做,通过Intent把暂停等命令出入进去,进度条也可以通过广播来发送出去,但是这样做,感觉很丑陋,肯定不是常规的高效做法);
第二种启动方式,可以在onServiceConnected中,获得一个Service对象(可能不是一个Service对象,至少是一个可以接触Service内部操作的句柄)。这样,便可以轻松操作播放和接收进度通知。但是这种方式有弊端,一旦与之绑定的context退出,则绑定接触,Service也会被回收(但是不会执行onDestory方法);
那么是不是就只是简单用第二种启动方式?
当然不是这样,在谷歌官方文档中,有交代,这两种方式并不冲突,而且十分适用于音乐播放类的应用。
原文如下:
A bound service
The service is created when another component (a client) calls bindService(). The client then communicates with the service through an IBinder interface. The client can close the connection by calling unbindService(). Multiple clients can bind to the same service and when all of them unbind, the system destroys the service. (The service does not need to stop itself.)
These two paths are not entirely separate. That is, you can bind to a service that was already started withstartService(). For example, a background music service could be started by calling startService() with anIntent that identifies the music to play. Later, possibly when the user wants to exercise some control over the player or get information about the current song, an activity can bind to the service by calling bindService(). In cases like this, stopService() or stopSelf() does not actually stop the service until all clients unbind.
简单理解是:可以有多个client去绑定同一个Service,并且只有所有绑定的client都解除绑定以后,Service就会被destory掉,不需要执行stopSelf方法,同样不会回调到onDestory方法;一个Client可以绑定一个已经start的Service,这样绑定的话,要停止这个service,则必须先解除一切绑定的client,然后再调用stopService或者stopSelf方法。
得到官方的说法后,就可以放心大胆的写代码了。
为了方便,我们定义一个自己的Application类——BeApplication,来执行相关操作。
在这个Application类的onCreate方法中,我们先启动一个Service,然后绑定这个Service。注意,让自己的BeApplication能够运行,要在manifest文件中的<application/>标签下,定义android:name=”包名加我们application类的类名”。
现在写我们用音乐播放的Service类——MainService,同样记得在manfest文件中声明这个Service。
注意之前在BeApplication中的onServiceConnected方法,我们在那个方法中,取得了由MainService中的onBind方法返回的IBinder对象,并通过这个对象,我们在BeApplication中拿到这个用于播放音乐的Service,这样以来,与Service交互容易的多。
也许你会问,这样已经拿到service对象了,那有何必要去start这个service呢?
注意MainService中的onStartCommend方法,此方法返回了一个int常量,对于这个常量,官方有这样的解释:
START_STICKY
If the system kills the service after onStartCommand() returns, recreate the service and call onStartCommand(), but do not redeliver the last intent. Instead, the system calls onStartCommand() with a null intent, unless there were pending intents to start the service, in which case, those intents are delivered. This is suitable for media players (or similar services) that are not executing commands, but running indefinitely and waiting for a job.