安卓开发之Android与设计模式

咨询 QQ:810476411
(3人)

249.50 元 5 折

全场5折优惠,咨询QQ810476411

www.androiddevtools.cn

 

gradle->任务驱动型构建工具,通过plugin插件扩展功能,以适应各种不同的任务。

 

Android最牛逼的地方->Intent

 

xjanker.github.io/akita

[展开全文]

多思考:人家的框架为什么这么写?不这么写有什么问题?

异步加载图片、加载大量图片(图片错乱、OOM...)

缓存策略-先进先出、最近使用、频率最小...

缓存内存设定最大值,在特定的大小中进行缓存,来使用内存快速读取功能(一般是前几张和后几张,让用户感觉不到加载的过程,加强和用户的交互)。

内存缓存中的重要概念:引用-引用又分强引用和弱引用。(大的图片缓存中使用)

看开源框架的example也是有方法的:

-Manifest.xml

-项目目录和风格

在xml中配置onClick--如果再去给View设置id,并在代码中获取,代码会显得很冗余。

Gallery用的越来越少,取而代之的是ViewPager。

ImageLoader

ImageLoaderConfiguration(对应用户使用性能有很大的影响)

项目中用到开源框架的话,建议在Application中对ImageLoader进行初始化,在以后进行应用。

AbsListViewBaseFragment-applyScrollListener-监听滑动事件,掩饰停止的时候去加载图片还是滑动的时候去加载图片-滑动过程中不会加载图片,停止滑动的时候加载相应的图片。-省流量和内存,交互和速度都能得到提升。

DisplayImageOption-Builder模式

讲到ListView/GridView..最牛逼的地方就是Adapter

所有的Adapter都要考虑到这一点:Image加载给ViewHolder的imageView。

 

ImageLoader

>ImageLoaderEngine

[展开全文]

SharePreference

数据库

文件

 

图片最头疼的就是OOM

[展开全文]

架构设计的精髓在于分层和设计模式的合理应用。

分层的核心在于架构层面进行抽象。这里所谓的抽象并不是面向对象中的抽象,说成沉淀更合适-沉淀是需要过程的(项目的进展,业务的变化和丰富,代码的重构和架构的沉淀是必须进行的一个过程(代码结构的整理、代码包名和类名的命名规范、没有用的代码整理、工具类的重用、提炼和沉淀出一些可以重用的组件和服务,上升到组件化---从代码的结构层1面上升到架构))。

 

分层的关键在于找到每个组件所处的层级。

!对单独APP来说

>业务逻辑层(核心的业务,增加用户黏性的相关业务逻辑)

>基础组件(登录、注册、API访问、弹出框、进度条等等可以共用的组件)

>服务组件(网络服务,数据库服务,文件服务,日志管理服务,GPS,数据打点、提交等等)-或多或少会用到第三方类库

[展开全文]

APP开发中,页面的开发工作量远多于纯业务逻辑的开发工作量。

如果不深入了解设计模式和软件架构的话 ,你就会慢慢的发现自己已经变成了一个前端开发人员,整天写一些复杂的界面实现。

因为移动操作系统很多概念的引入,移动开发中的设计模式和软件架构思想慢慢被弱化。(四大组件的概念绝大程度上屏蔽了进程、线程等等传统软件的概念)->学习Android,就应该剥开Android本身的一些理念看一下它的实质的思想,把一些好的传统软件开发中的理念、思想逻辑加进来,打造一些优秀的架构。

界面布局资源里用到的模式和架构。

底部Tab的两种主流实现方式。

>mListView展现了2项,一个是传统的ViewPage实现的底部Tab风格,还有一个就是FragmentManager(就是Fragment(天然适配大屏幕,天然的MVC架构-把一些业务逻辑都抽象出来//生命周期和Activity类似,但不同之处在于它业务逻辑和生命周期耦合性更弱一些,用起来更方便一些),推荐,能用的时候就用)。

>如何加入复杂业务逻辑?

>抽象出MainTab,demo的方式展现。Tab1\Tab2...很冗余。

>相应的内容是4个Layout,不同的布局。写在一个Activity里->setTabSelection(0)

>思考:在每一个Fragment里面想要加载一些相应的网络数据或者本地数据的时候-当前第一个Tab,点到第二个Tab话重新加载网络数据或者Load本地数据,再点回到第一个Tab之后呢,希望这个Tab不去获取网络数据(目的:给用户节省流量)-在Tab切换的时候,怎么才能自主的决定是否去请求网络数据呢?

 

为了新建一个相应的布局,在布局中使用设计模式和架构思想。

 

为什么不用ListView这样更简便的方式去实现呢?主要是为了展示在布局里面可能会用到的include这样一个简便的、与设计模式相类似的思想。

网络访问->网络通信框架(使网络通信尽量的更快、更简单、更健壮..提供的功能:提供便利的处理逻辑-JSON、图像等等的异步下载,网络请求的排序、请求的优先级处理,缓存,请求失败后的异常处理,以及和Activity生命周期的联动 (当Activity结束的时候,同时取消所有的网络请求)) ->实现思想及优缺点-更好的加以利用(无非就是2种-数据的提交和数据的下载-且网络数据是耗时的操作,一定要放在后台线程去完成,又牵扯到线程同步的问题。异步线程的处理方法。)->如何集成到自己的app中,如何构建合适的Controller层(MVC),把业务组装起来,方便上层调用,在Android中就是方便Activity、Service等不同组件在不同生命周期当中进行调用。

为了满足不同模块的不同需求,不同的模块相对应的这个模块的Controller肯定是处理不同的业务逻辑的。需要把不同业务逻辑相应的Controller实现的一些基本的流程抽象到一个基类中。

[展开全文]

基础框架

>页面展示模块

>网络交互模块(网络数据获取以及本地数据提交)

>数据持久化模块

>自定义View

>工具类模块

 

》抽象出具有普遍规律性的模块框架->一个框架的优劣取决于当时的业务需求,能符合业务需求的框架就是一个好的框架。目标是写最少的代码实现最复杂的业务,并且具有 扩展性来适应业务需求的不断变化。

 

BaseActivity extends Activity

>TAG

>onCreate()

.初始化ImageLoader(图片下载/图片缓存/内存缓存/硬盘缓存/容错机制/图片异步加载/包含ListView、GridView、ViewPage等多个图片展示方式的交互模式->介绍框架的文章,学习核心思想和架构模块结构)->为什么要把图片框架放在Activity的基类中呢?合不合适?(不合适,除非是一个与图片相关的APP,每一个页面都涉及图片处理)

基类就是要抽象出子类的共同点(设计模式基本理念)最常用、最直接、最有效的办法,也是最容易出错的办法->哪些是共同点,哪些提取到基类,哪些留到子类中具体实现

.检测网络状态

也是不恰当的,为什么每一个Activity都要检测网络状态呢?难道没网络,APP就不运行了?没有本地数据缓存机制?

(工具类都是静态方法

CommonTools->工具类的命名和方法堆积不当)

>openActivity()/openActivityForResult()

APP页面展示的最理想状态是风格统一,不单单是指页面、色调、尺寸统一,还要包括页面的跳转特效统一->在基类中抽象出跳转的一些方法

>startShowBusy()/stopShowBusy()

涉及页面展示的数据来源:网络、数据库、本地缓存,每一个页面的数据不管是从网络下载还是从本地加载,肯定是在子线程里执行->为了不出现ANR状况,也处于友好性的考虑,需要一个ProgessBar展示给用户,让用户进行等待(不展示数据的页面,包括设置、意见收集...)

 

 

HomeActivity extends BaseActivity implements OnClickListener

>onCreate

.setContentView()->看xml布局

最完美的页面层级数量:3-4级,再深就找别的方法进行优化,否则一定会影响加载效率。>Android碎片化的问题,多考虑性能问题。

.mHandler =  Handler(....)

主要用来处理广告页的自由滑动

大块的代码之间放在onCreate()中?->写一个新的方法或类来处理这些逻辑

.initData()/intView()

.初始化dbUtil数据库访问工具??->只是为了log,而且log没做开关,很容易被别人看到

.findViewById()->最好不要用与系统容易混淆的命名//初始化放在initView中,否则别人改你的代码很容易报空指针(initView没有 

.开启Service,代码量不多,还是建议放在方法中,并且方法取一个直观的函数名称

>public class MyAdapter extendsPagerAdapter

.广告页的PagerAdapter,最好不要放在这里

>MyPageChangeListener implements OnPageChangeListener

>onClick(...)->处理页面的挑战和button的点击事件//不太习惯把整个Activity实现一个Listener,如果要寻找跳转方法,需要查询整个java文件,并不是特别直观,并且button必须设置成类的成员变量,并不能用一个局部变量直接解决

>onKeyDown()

>生命周期打点->统计用户使用情况,完全可以放在基类BaseActivity里面去执行,还可以在基类中抽象一个方法来返回子类中String类型的标志->共同的部分抽象到基类中

 

MyStationActivity,清晰直观!

.AsyncHttpClient

 

通过代码构建框架

。包名有了>把东西进行模块化的划分(MVC)

.ui(Android本身就有一个View的概念,叫UI,UI里面可能会有Activity/Fragment)

>扩展网络数据的获取>Handler(Hanler消息发出去以后,Fragment/Activity Finish了,消息还存在,等到消息处理逻辑涉及到Activity类的上下文环境的时候就会报错->需要把Handler的操作进行约束,防止溢出->抽象出一个NoLeakHandler)

[展开全文]

页面网络访问、多线程框架的搭建

选出主要app进行着重运营,其他app做成插件/功能模块,嵌入到主要app中。(360手机管家可以下载360电池医生) > Android中有哪些可以解决的技术方案,并且分析每种方案的利弊。

实际开发中的问题没有解决不了,只是代价大小。

设计模式对Android架构的理解,以及对每个组件的详细理解就能很好的规避问题的出现。等到问题出现的时候,就能明白为什么出现这些问题,并不是急着去Google......->找到解决方案要的总结

设计模式落实到项目架构层面就不空洞了,是一个具体的体现。单单评价项目框架的好坏并没有意义。项目进行到不同的阶段,有不同的框架与之对应。

每个框架有针对某一具体问题存在的理由。

通过模块框架搭建过程把Android开发中经常遇到的问题暴露出来。->同一个问题也可能有不同的解决方案,根据不同的项目需求采用不同的框架、解决方案。

不单单是实现UAD画的界面,要有自己的代码积累(自己维护的类库)

 

 

Android应用界面设计分析(从Android5.0开始,系统界面在一致性有了很多改善,一些指导性的要点,也正在被第三方应用采用。)

-起始界面

-分界面

-列表界面

-载入列表

-长按操作界面

-多选操作

-标签界面

 

引导页-ViewPage

 

起始界面

eg.微信

->风格的统一

->Tab

 

分界面

->TitleBar->在布局文件里面怎么写?是否用Include?是在BaseActivity里面写还是在每个Activitiy里面写?哪天产品设计说要在TitleBar里面加个ProgressView怎么办?加入网络错误显示怎么办?->有一个这样的扩展,有一个顶层设计的思想去考虑问题,考虑界面。(APP 60%的工作都在界面上,然后是数据,然后是逻辑,然后是网络,然后是持久化,然后是性能调优...)->界面能形成组件,形成代码积累,形成框架,才能腾出更多的精力去focus代码业务逻辑。

 

列表界面(ListView)

手机页面比较小,分三级展示信息:

1.九宫格

2.列表(//现在大屏,列表功能丰富(列表里面放了图片、按钮、复选框)->长按/短按/侧滑/其他操作..->对列表有没有自己的代码积累?框架积累?(下拉刷新,上拉加载有多少框架可以用?)提到列表实现的时候(适配器模式),有没有想到一些问题?是不是重用?是不是用一些方法让它效率更高?如果提出需求,每一个ListView里的Adapter都不同->不关只是要有观念上、理念上的积累,还要有实际代码上的积累)列表是最显示程序员功底的界面->怎么加载/同步/跨线程操作/刷新UI//列表的性能...

3.详情 下拉刷新,上拉加载

>>列表操作(删除...网络上多个框架的分析,多选操作...)

 

界面总结

应用界面逐渐形成一套统一的规则和界面应是一个大体趋势。

虽让Google并没有在界面上给出太多限制,但是随着Android平台的发展,应用界面逐渐形成一套统一的规则和界面应是一个大体趋势。一套产品,若要给用户留下良好的第一印象,就需要认真考量跨平台的设计问题,无论在交互层面还是视觉层面。当然这并不意味着所有的设计都必须千篇一律,如果你的界面能够保证易用性的同时又有不俗的视觉表现(Path),不妨去大胆创新。

不过,遵循原生系统的现有规范还是会减少你大量的开发成本。

 

Fragment

为什么在3.0加入Fragment,为了Fragment还加入v4、v7的包?->Fragment实际项目中替代Activity->大屏时代的到来,适配Android的碎片化,更灵活的运用在各个设备。

->Fragment生命周期

->Fragment怎么样和Activity进行交互

->Fragment跳转Activity怎么样传数据,怎么样加setContentView,它的生命周期,它的处理逻辑

 

开始项目的时候->定下规范:包名/项目名/模块...

Android程序运行的第一个函数->Application的onCreate()

Application是什么?是Android框架的一个系统组件。

Application能干嘛?Android系统默认为每个Android程序创建一个Application类并且只创建一个(单例模式)。Application的整个生命周期是整个程序中最长的,等同于整个程序的生命周期。不同的Activity或Service都是同一个对象,通过Application就可以实现传递数据/数据共享/数据缓存(全局)。

静态View缓存到Application中要进行释放

每一个组件都会提到生命周期

onCreate

onLowMemory

onConfigurationChanged

 

ApplicationContext

 

不好的地方->在Application里面做了很多操作,包括网络访问/数据库/定位....->尽量消减在Application中的耗时操作

Application可以获取应用程序的资源和类,进行应用程序级别操作->可以执行发送广播/接收Intent信息...

 

反面教材:

BaseActivity->提取共同操作

页面层

[展开全文]

脱离了程序开发的设计模式没有意义

 

Android中5种布局

为什么FrameLayout和ViewGroup是同级的?

 

View

View represents the basic building block for user interface components.

A view occupies a rectangular area on the screen and is responsible for drawing and event handling.

View is the base class for widgets, which are used to create interactive UI components(buttons,text fields,etc.).

The ViewGroup subclass is the base class for layouts, which are invisible containers that hold other Views(or other ViewGroups) and define their layout properties.

>View的作用:展现丰富多彩的视图页面,显示用户的输入,点击,动画以及一些处理结果。

>开发超过50%的时间花在UI上。

>掌握基本理念、技术难点

 

ViewGroup & Layout

View是所有View子类的父类 分为Layout(布局)和Widget(组件)2种

ViewGroup的各种Layout>组合模式(Composite)

 

Layout & Widget

->RemoteViews

Widget的Layout是基于RemoteView的,而RemoteView并不是支持所有的Layout。

 

View的创建(每一个Activity组件都有一个关联的Window对象,这个Window对象是用来描述应用程序的窗口,每个应用程序的窗口内部又包含一个View对象,用来描述应用程序窗口的视图。这个应用程序窗口是真正用来实现View内容和布局的。每个Activity组件的UI内容和布局都是通过与之关联的Window对象的内部的View对象实现的。)

我们在Android系统中强化了View的概念,并且主要在对View的管理方面。弱化了Window的概念,并没有把Window的概念提高到应用开发的层级。Android中View以两种形式存在:单一的View和多个View组成的ViewGroup。在一个Activity窗口中如果添加多个View的话,就实现了窗口系统的UI多样化。怎么对ContentView进行管理?它的内部逻辑又是怎么样的?(View的创建方式有2中:1.xml配置,2.java代码实现)

Activity.setConentView()->getWindow().setContentView()->Window mWindow(里式替换原则)->attach()里面赋值->PolicyManager返回一个PhoneWindow对象

->java对象初始化过程:静态代码块->构造代码块->构造函数

->new关键字->创建新类/newInstance方法->使用类加载机制--考虑到软件的可伸缩性,可扩展性以及可重用性的软件设计思想

->PolicyManager提供静态方法接口用于创建... 实际上属于工厂方法...

>通过PolicyManager动态加载一个Policy的类

>Policy(IPolicy)->创建具体对象的接口(动态加载+工厂方法->降低耦合,提高代码灵活性、可扩展性)

 

 

 

PhoneWindow.setContentView()

->mContentParent(installDecor()/...)

(->Window.java->findViewById()>getDecorView()...) ->每一个PhoneWindow都有一个ViewGroup类型的对象mContentParent

->generateLayout(mDecor)

>View in = mLyaoutInflater.inflate(...)>XMLPraser

>decor.addView(..)

 

View层级

>System Layout 包含ActionBar,FullScreen等属性...

>用户所有新增加的View都会包含在mContentParent中。

>为什么叫做setContentView而不是叫setView? 因为是给mContentParent设置子View

 

PhoneWindow:是Android中最基本的一个窗口系统,每个Activity都会有一个PhoneWindow对象,是Activity和整个View交互的一个接口。

DecorView:当前Activity所有View的祖先,并不会向用户呈现任何东西,主要是用来:分发事件\有一个直接的子View-System Layout(从系统的layout.xml中解析出来,包括当前UI风格,是否带Title,是否带ProcessBar...(属性通过Window设置进来),在setContentView()方法之前调用)

mContentParent:这个ViewGroup才是真真正正的ContentView的Parent。mContentParent是System.Layout中id为content的FrameLayout。每个System Layout都会包含一个id为content的FrameLayout。

Activity Layout:设在mContentParent中(为什么叫setContentView)

 

装饰模式Decorator

装饰模式以对客户端透明的方式扩展对象的功能,是继承关系的一个替代方案

它是以对客户端透明的方式动态的给一个对象附加上更多的责任。(给Window加上View的责任)也就是说,客户端并不会觉得对象在装饰前和装饰后有什么不同。装饰模式可以在不适用创造更多子类的情况下,将对象的功能加以扩展。

装饰模式还是用处很多的,例如需要扩展一个类的功能,或给一个类增加附加责任。需要动态地给一个对象增加功能,这些功能可以再动态的撤销。需要增加由一些基本功能的排列组合而产生的非常大量的功能,从而使继承关系变得不现实。

PhoneWindow通过DecorView这样一个View的概念把本来已经弱化的Window的概念引入进来,把Window这样一个概念进行装饰,装饰成View。

DecorView所起的装饰模式作用?

1.为什么函数被称为setContentView()

每个System Layout都包含一个Title和id为content的FrameLayout,自定义的View会添加到这个FrameLayout当中。

2.初始化DecorView的时候,所有窗口的样式和特性配置必须在setContentView之前,以便于PhoneWindow的一些属性可以解析出来。

3.所有视图的root Layout(根布局)都是一个FrameLayout

 

inflate()方法->XML解析流程

inflate()方法会调用Resource的getLayout()方法,调用一系列的解析方法,然后调用AssetManager,通过getSourceValue()来调用id文件的名称,然后返回一个Parser, 然后根据相应的一些Tag,通过反射的机制来创建一些View。然后把调用的一些方法传进去的参数是否需要再添加到Root View当中。

>我们在做一个View时候,层级不要太深,层级太深的话,它的循环会很多,加载会很慢。

 

几个重要的标签

Include->当一个布局文件可以在多个页面中使用(TitleBar...),减少重复工作

Meger->减少View的层级(把子View直接添加到父View的Layout当中),加快界面加载速度,和Include结合使用(配置一个Merge,然后通过Include加入到父Layout中)

Blink->4.0加入,实现闪烁提醒

StubView->项目需求:根据动态条件决定是否显示哪个view或者某一个布局。最常用的方法就是把可能用到的View全部写上,设置它的可见性为View.GONE,然后在代码中动态地改变它的可见性-控制简单,设计起来比较灵活。缺点:层级比较深,耗费资源,拖慢了View的加载时间->推荐通过StubView(轻量级的View,看不见的、不占布局位的、占用资源非常小的控件。可以为stubview指定一个布局,然后在inflate布局的时候,只有初始化,并被设置设置可见的时候才会调用Inflate、才会被实例化。然后StubView的布局都会传递给它指向的那个布局,然后就可以通过stubView方便的在运行的时候来选择显示这个布局还是不显示这个布局。)StubView只能inflate一次,只能inflate一个布局文件,之后StubView对象都会变为空。

requestfocus->获取焦点

 

View的绘制流程

>..

>重新Measure:通过设计实际的宽度和高度来进行计算,通过回调(setMeasureDimension)

重新Layout:根据子数组的大小及布局的参数将View放置到合适的位置上。

重新Draw:View Root对象进行重新的绘制

 

1.绘制该View的背景

2.为显示渐变框做一些准备操作(大多数情况下用不到)

3.调用onDraw()方法绘制视图本身>自定义view需要实现的函数,需要重载的方法

4.调用dispatchDraw()方法绘制子视图(不包含子视图的时候就不需要重载次方法,ViewGroup已经为我们重写,一般不需要)

5.绘制滚动条。

 

View的事件分发

dTE->根元素无限往下传递,一直到内层元素或中间某一层元素停止传递的时候,就是处理完成了。

return True->事件分发给当前View,并且dTE方法进行处理,事件停止往下传递。

return False->

分成2种情况

>事件直接来自于Activity,就会返回给Activity的oTE方法

>View获得事件的话,返回给父View的oTE方法。

 

oITE是事件拦截,返回系统默认情况。

 

思考具体的应用场景->三个类、三个层面

 

自定义view

自定义layout>要继承ViewGroup类,必须实现的方法为onMeasure(),onLayout()方法

自定义widget>要继承View类,必须实现的方法为onMeasure(),onLayout()和onDraw()方法。 

 

view的优化(view的层级会严重影响界面流畅度,考虑加载性能) 

{

Meger

Include

stubView

}>在开发阶段把一些复杂关系的View给规避掉

hierarchyViewer > 分析View视图,测试的层面进行优化

[展开全文]

extensibility

flexibilitty

pluggability

open_closed principle opc

liskov substutution

开闭原则

一个如阿健尸体如雷,模块和函数应嘎争体制嘎嘣接啊u需要改股阿奴,

用抽象构建框架,用实现拓展细节。解决问题的关键在于抽象画

一劳永逸、不在更改的抽象设计

用抽象构建框架,用实现扩展细节

关键在于抽象画

在任何情况下都不需要改变

对修改关闭

android 创在出一种intent和你疼filter配合的低耦合的交互模型

activity 带显示与交互能力的部分

service 不带显示与交互能力的部分

conent privider

brodcas receiver

android 中的抽象设计

intent  intent filter 

 

历史替换元阚泽

里氏替换原则

自雷可以拓展父类的功能名单不能改变父类原有的功能

子类可以实现父类的抽象方法,蛋不能覆盖父类的非抽象方法

子类中可以增加自己特有的方法

当子类的方法重载父类的方法时,方法的潜质条件,及方法的形参,要比父类的方法的输入参数更宽松

当子类的方法试下父类的抽象方法时,方法的后置条件要vfukeu分工他保护费

 

以来导致

高层哦快不应该以来底层模块,二者都应该以来其抽象

抽象不应该以来细节

细节应该以来抽象

 

 

 

 

[展开全文]
雨鯚 · 2015-09-13 · 设计模式简介 0

到了这个课时,我基本上没什么要说的了,但还要说一些。

我现在明白为什么“课时10”到“课时13”的主题叫“基础框架搭建一、二、三、四”,因为老师提炼不出来重点,没有对课程的内容进行设计;

可笑的是,视频内容里,老师总是提到程序的设计如何如何,不知道老师对于自己的课程教学内容设计做如何评价?!

还有2点我不明白:

1、既然视频录制时敲代码费时,为什么不拿一些现成的代码来给我们展示,我觉得主要是明白思想及设计思路,并不是要听敲代码的声音;向Manager类和Helper类,都可以展示,我们正好可以看看实际业务中都在怎么用的。

2、不清楚“课时10”到“课时13”录制的目的是什么。我们这个课程叫《安卓开发之Android与设计模式》,先不说这4个课时讲没讲设计模式,连“设计模式”这4个字都很少提到。

我不清楚这个课程往下进行将去向何方!

 

[展开全文]

从前十五分钟的内容来看,老师是毫无准备的,没头没脑地说了半天程序的分层和架构,忘了我们这个课的主旨是什么了,当然我能理解老师的用心,希望我们能学习到一些他的经验,但我希望也是系统的有计划的清晰明了的说出了,而不是这种混乱的教学方式;接下来,敲击无用代码浪费的时间占了60%、70%,“sendMessage方法”的几种重载,“FeedbackBean类”的编写,天啊,我都要疯掉了,这些是应该在视频中出现的过程吗?!!!这些和我们这个课程要讲解的有什么关系?!!!这些是不是应该准备好,我们看视频时看到写好的代码,都会知道他是在干什么的!!!难道老师认为我们的水平不行吗?!!!您到底在接这个课时,在您准备将这个课时,自己对学员有没有一个编程水平的定位?!!!我们交钱看您的视频,是看您写这些代码的?!!!;

老师一再强调本课不会讲基础,java基础也好,还是android基础也好,但是在代码编写上浪费的时间,都是因为这两块浪费的;不知道老师在录制课程时,是否有一个规划,本节课应该讲什么,讲到什么程度,哪些需要备课时就要准备好的,哪些需要在边录制边讲解边做的

NetThreadManager类,绝对不应该在视频中敲代码,应该是展现给我们一个写好的程序,简单讲解即可;因为该类可以说和这个课要将的毫无关系,就是一个工具类,在非Android程序中也会用到,所以应该点到为止,告知我们如果有不明白的,去网上找找相应的例子和解释。而老师恰恰却把这个类写得相对完整(相对于哪些?下面会说到),从34分30秒到47分55秒,都是在说这个类!!!

什么应该把代码写的相对完整一些,或者伪代码写得相对完整一些,或者todo的中文注释写得相对完整一些,我看了48分钟,我觉得起码以下两个:1、“NetManager类”,它的定位是什么,是工具类,是网络访问管理类,应该都是一些抽象的方法实现;而“doAddFeedback方法”,它是一个很具体的业务,为什么要放到“NetManager类”里面?!这个是反馈,如果还有相关数据获取,登录操作,用户行为记录等等需要访问网络的操作,都要放到这个“NetManager类”里面吗?!不放在这个里面,那么如何设计?是否就需要某种设计模式的支持?2、回调机制,Android中很多地方用到了回调机制来处理,这里是否需要将代码或伪代码或todo中文注释写完整些?!

课时内容不充实,这节课干脆连视频都没有结束,是录制问题,还是态度问题?

[展开全文]

Tab1从网络中加载了数据,当从Tab1切换到Tab2后,再从Tab2切回到Tab1,如何让刚刚加载的数据不再去请求网络而直接显示出来?!

[展开全文]

1、NoLeakHandler到底是做什么用的,没说明白!

[展开全文]

遵循依赖倒置原则可降低类之间的耦合性,提交程序稳定性,降低修改程序出错风险。

依赖倒置的核心是面向接口编程。

 

枚举单例的3个有点:

1.枚举写法简单;(最大的优点)

2.枚举自己处理序列化;

3.枚举是thread-safe的。

 

 

[展开全文]
Eban · 2015-06-08 · 免费试听 0
  1. 21分钟没有看懂!
[展开全文]

fragment

fragment是为了替代fragment,为了适应大屏,不同尺寸


[展开全文]

frameLayout和其他四种


View()

ViewGroup  imageView textView

linearLayout relativeLayout frameLayout

listView

有的组件并不支持四种layout


重要标签

include减少重复工作


meger减少view层级,加快界面加载速度,把子view加入父类界面

blink闪烁提醒

stubView动态决定是否显示view,轻量级view,被使用时才载入布局并显示


requestfocus获取焦点

<requestFoucs/>


view的绘制流程

measure ->layout->draw


优化:三种标签 和 hierachryviewer(分析工具 )

[展开全文]

四大组件

Activity

task是一组activity的组合


activity启动模式

利用 launch mode决定启动模式:

standard singleTop singleTask singleInstance

Service

启动方式: 通过startService启动

通过bindService绑定

处理与用户无关的业务逻辑,一般都是后台计算

Service不应该处理耗时操作,不会单独启动一个单独进程也不是单独的线程,与所在应用位于同一进程

intentService使用队列管理请求,会开启一个新的work线程处理具体请求,保证同一时刻处理一条,可以处理耗时操作


broadCast

在组件之间进行消息传递,可以跨进程,在bind进程间通信的基础上进行的

Content Provider

不同应用之间的数据共享

<activity> <service> <receiver> <provider>

四大组件都有一个process属性来制定组件运行的进程


Android中的线程

UI只能在主线程中更新, 但是有五种方法在子线程更新UI:

Handler

Activity.runOnUiThread

View.post

View.postDelayed

AsyncTask


[展开全文]

1.可扩展性

2.灵活性

3.可插入性

[展开全文]
踏歌梁月 · 2015-01-24 · 0

结构型模式

1.Adapter适配器模式

类适配器模式

对象适配器模式

2.桥接模式

3.合成模式

4.装饰模式

5.外观模式

6.享元模式

7.代理模式

[展开全文]

授课老师

Android架构师

学员动态

RanDongmei 开始学习课时 免费试听
fzhu129 开始学习课时 基础架构搭建二

QQ客服: 810476411

QQ咨询: 810476411

QQ吐槽: 810476411

服务时间: 9:00 - 21:00

刘老师: 18516031455

微信公众号:开源力量